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

[Brad House <brad@monetra.com>]

>> 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.


That's my thought too, especially with AES-NI.


>> 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.


Ah, ok, that's good to know.  Thanks.


>> 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.


Well, since Intel provided a specific CTR mode AES-NI patch and
it referenced testing it _using_ dm-crypt
(http://lwn.net/Articles/376562/), I'd assume it is possible to at
least use it with dm-crypt ;)


> 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.


No specific security requirements.  I'm not worried about
governments targeting breaking this encryption or anything
like that.   Just want to make sure the actual storage of this
data isn't the weakest link in the security chain.


> 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.


Sorry, I should have provided more information...

The requirements are basically if the box leaves the building,
that it be infeasible that the plaintext data be retrieved.
Not worried about leakage of statistics or even modification
of data, though if those too can be prevented for little cost,
it'd be nice to have ;)


> 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.


This is a multi-user fileserver hosting remote home directories
(just across the LAN) for Linux and Mac users, primarily developers,
who could be doing anything from compiling code, to tar'ing files,
to heck, even running a VM from the network filesystem (though
that last one won't exactly be recommended).

It _will_ be a pure SSD RAID subsystem (LSI 9260-8i RAID 5 using
8 Intel 320series SSD drives), and interconnected to our network backbone
with a 10Gb/sec interface (SFP+ twinaxial direct-connect).  Though
each developer's workstation will be limited to gigabit speeds, the
aggregate of multiple workstations could be higher, and we don't
want the remote share to be a bottleneck.

A combination of NFSv3 and NFSv4 will be used, I'd need to research
this point, but I'd assume each workstation's connection would be
handled via its own process or thread within NFS, so it should be
able to scale multi-core.

Thanks.
-Brad