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@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
