From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
	by finch.gentoo.org with esmtp (Exim 4.60)
	(envelope-from <gentoo-user+bounces-136252-garchives=archives.gentoo.org@lists.gentoo.org>)
	id 1S7WJy-0001f5-TA
	for garchives@archives.gentoo.org; Tue, 13 Mar 2012 18:19:44 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
	by pigeon.gentoo.org (Postfix) with SMTP id 69351E08EE;
	Tue, 13 Mar 2012 18:19:29 +0000 (UTC)
Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53])
	by pigeon.gentoo.org (Postfix) with ESMTP id 164B2E0B58
	for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 18:18:21 +0000 (UTC)
Received: by bkwj4 with SMTP id j4so792472bkw.40
        for <gentoo-user@lists.gentoo.org>; Tue, 13 Mar 2012 11:18:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=tX8IK2zD/1Hp40Nu8kNebNBjYOmJDb8EB3QOCu1lA1o=;
        b=cI7ztTGd2MCfNjg0kImOza6BowT5VU9xacKHWvWQ4Ahl4zwrEXn2T5RVM0ZVrpbyqi
         /e4zJ/Qbz7AbMWPiu9YN8QDFC8585BI60x+jn6I7B4um7CUzi2WLDXIQXy+GI+9rBQJs
         hhu6HaYzheC1rL1HVkCh5WqwENvbWnE0bsFp4d57AaiX+uE32+3+RIz1jyNXw1mDLEWq
         4c9QIRazYVyDLdIv5Iz24YrGKiSDhujVsQvv4COb20TIbZoiZYAE7wx6XQAUBf64WDoZ
         +gYE6F18+muIhXygKHDhWxd/Q9FvBlyVJCZgLobkCLSFxpxIKMJGeazpoe95WQugregl
         9xQQ==
Precedence: bulk
List-Post: <mailto:gentoo-user@lists.gentoo.org>
List-Help: <mailto:gentoo-user+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-user+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-user+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-user.gentoo.org>
X-BeenThere: gentoo-user@lists.gentoo.org
Reply-to: gentoo-user@lists.gentoo.org
MIME-Version: 1.0
Received: by 10.204.10.66 with SMTP id o2mr6729234bko.30.1331662701100; Tue,
 13 Mar 2012 11:18:21 -0700 (PDT)
Received: by 10.204.168.17 with HTTP; Tue, 13 Mar 2012 11:18:21 -0700 (PDT)
In-Reply-To: <4F5F8CC3.7070402@binarywings.net>
References: <4F5CC6F5.6020303@gmail.com>
	<4F5CEF0D.5050801@binarywings.net>
	<4F5F35C1.8070301@gmail.com>
	<4F5F71C3.6070206@binarywings.net>
	<20120313174555.GA15334@eisen.lan>
	<4F5F8CC3.7070402@binarywings.net>
Date: Tue, 13 Mar 2012 14:18:21 -0400
Message-ID: <CA+czFiCcDMz7nMhfabGL6iRL4ecd+cxWdhu3ZeGSQeJf_MKM1Q@mail.gmail.com>
Subject: Re: [gentoo-user] hard drive encryption
From: Michael Mol <mikemol@gmail.com>
To: gentoo-user@lists.gentoo.org
Content-Type: text/plain; charset=UTF-8
X-Archives-Salt: 4cb31809-c12d-4547-ba1b-2d4d5f37e90b
X-Archives-Hash: cf98fd8e5c17bf2dcb41e0cb3f653a71

On Tue, Mar 13, 2012 at 2:06 PM, Florian Philipp <lists@binarywings.net> wrote:
> Am 13.03.2012 18:45, schrieb Frank Steinmetzger:
>> On Tue, Mar 13, 2012 at 05:11:47PM +0100, Florian Philipp wrote:
>>
>>>> Since I am planning to encrypt only home/ under LVM control, what kind
>>>> of overhead should I expect?
>>>
>>> What do you mean with overhead? CPU utilization? In that case the
>>> overhead is minimal, especially when you run a 64-bit kernel with the
>>> optimized AES kernel module.
>>
>> Speaking of that...
>> I always wondered what the exact difference was between AES and AES i586. I
>> can gather myself that it's about optimisation for a specific architecture.
>> But which one would be best for my i686 Core 2 Duo?
>
> From what I can see in the kernel sources, there is a generic AES
> implementation using nothing but portable C code and then there is
> "aes-i586" assembler code with "aes_glue" C code.


> So I assume the i586
> version is better for you --- unless GCC suddenly got a lot better at
> optimizing code.

Since when, exactly? GCC isn't the best compiler at optimization, but
I fully expect current versions to produce better code for x86-64 than
hand-tuned i586. Wider registers, more registers, crypto acceleration
instructions and SIMD instructions are all very nice to have. I don't
know the specifics of AES, though, or what kind of crypto algorithm it
is, so it's entirely possible that one can't effectively parallelize
it except in some relatively unique circumstances.

-- 
:wq