Re: [dm-crypt] Recommended modes for performance (SMP+AES-NI)

[Arno Wagner <arno@wagner.name>]

On Mon, Jun 27, 2011 at 11:38:44AM -0400, Brad House wrote:
> We're in the process of building a new fileserver which will
> be using dm-crypt, and are trying to get a game plan together
> on what mode of operation will be best for a good ratio of
> performance and security.
> 
> Initially the machine will be a 6-core Xeon which supports
> the AES-NI instruction set, but a second identical CPU may be
> dropped-in, in the future.  It will be connected to the network
> by at least one 10Gbps NIC.
> 
> Obviously, we'll be making sure to use 2.6.38 or higher in
> order to utilize the multi-cpu scaling enhancements to
> dm-crypt:
> http://kernelnewbies.org/Linux_2_6_38#head-49f5f735853f8cc7c4d89e5c266fe07316b49f4c
> 
> I think we've settled on AES-256, but may entertain AES-128
> if there is a huge performance difference as I think AES-128
> is still considered sufficiently safe for our purposes.

The performance difference should be relatively small.
 
> So, the question is mainly what mode of operation would be
> best?
>  - cbc-essiv
>  - ctr-{plain64|essiv}
>  - xts-{plain64|essiv}
>  - are there any others I should be considering?
> NOTE: I'm not sure if essiv is even an option for CTR or XTS
>       modes, I'd like feedback on that, as well as what the
>       security implications are...

ESSIV is only for CBC.

> At this point, I'm leaning towards CTR mode, mainly because it
> was designed explicitly to be parallelizable:
> http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Counter_.28CTR.29

That is only for fine-grained paralellism, and hence not 
applicable here. I am also not sure whether you can even use it
with dm-crypt as it needs a nonce in addition to the counter.
And that needs to be stored somewhere.
 
> And it appears Intel has explicitly submitted a patch to optimize
> dm-crypt for AES-NI with this mode of operation:
> http://lwn.net/Articles/376562/
> 
> I know "test it" is going to be the obvious answer, and we will,
> but I don't want to make any decisions that could severely impact
> security for a little extra speed.  Well, that, and our hardware
> is on order and probably won't be in for 3 weeks ;)
> 
> Any suggestions/feedback would be greatly appreciated.

Unless you have any specific security requirements beyond
the standard, go with the defaults. I think you are 
overthinking this. The defaults are what is maintained best 
and also what will get the fastest fixes and problem detection.

If you have special requiremenrts, any deviation from the
defaults should have a strong justification comming from
these requirements. As you have not given any, I cannot
comment on them.

As for speed, AFAIK, basically you are still limited to
one CPU per process that accesses an encrypted disk.
But keep in mind that with the defaults you get something
like 100MB/s crypto speed in pure software. Unless this thing
has an 2.5 or 10Gb/sec interface, and SSDs or mostly 
linear, large-file accesses, that is quite fast enough
in most cases.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier