On 06/27/2011 07:00 PM, Brad House wrote: >> ESSIV is only for CBC. yes, but nothing will stop you to use it for other mode (even if it is needed or redundant, like for XTS) >>> 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 ;) You can "use" it, again - dmcrypt will not stop you when doing that. (try e.g. -c aes-ctr-plain64 -s 128) Internally, it should use generated IV (plain64 - sector number here) as concatenated nonce + counter, crypto API CTR implementation then increases counter part when walking through block device sector using cipher block steps. So it "works" somehow. It is not tested at all though for use with full disk encryption:) >> 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. Exactly. Default is still CBC mode with ESSIV, XTS is more and more used, so it is possible that in future XTS mode will be become default in cryptsetup. Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
