On Fri, Jan 04, 2013 at 01:18:33PM +0100, Milan Broz wrote: > On 01/04/2013 12:53 PM, Ralf Ramsauer wrote: > > On 01/04/13 12:50, Milan Broz wrote: > >> On 12/29/2012 10:40 PM, Milan Broz wrote: > >>> The testing release candidate cryptsetup 1.6.0-rc1 is available at > >>> > >>> http://code.google.com/p/cryptsetup/ > >>> > >>> Feedback and bug reports are welcomed. > >>> > >>> Cryptsetup 1.6.0 Release Notes (RC1) > >> > >> I am going to do one more important change to final 1.6.0: > >> change LUKS _default_ cipher to aes-xts-plain64 with 512bits key. > > 512bits Key? > >> > >> Most of recent disk encryption systems switched already to XTS mode, > >> also it is preferred by standards (and we are using it for very long > >> time in Fedora/RHEL during installations.) > >> > >> Distro maintainers can always overwrite this during compilation time, > >> and user can use -c aes-cbc-essiv:sha256 -s 256 to old mode always. > > > You mean 256bits, don't you? > > For XTS? No, I meant 512. > > XTS uses 2 keys (for tweak and encryption). So with AES and 512bits > we will use 2 x AES-256 in fact. > But yes, question is if AES-128 (IOW 2x128 = 256 bits) is not enough here. Lets stay with 512bit. A good rule for key-lengths is to determine what is very likely secure and then use twice that. > (With all know analysis to AES256 I still think it is better > to prefer it to AES128. > But not 100% sure if any problems I missed, that's why I sent this mail :-) I think the current state is that in absolute terms AES256 is at least as secure than AES128, but maybe not more so. > XTS mode has some problems too but I am fairly sure it s still > better than CBC today (as default). Indeed. And AFAIK the problems are mostly with large blocks and do not apply to LUKS as the blocka here are only 512 Bytes. > People who exactly know what they are doing can > always switch the cipher during format time. > (Or later change it with reencrypt tool). And people that do not know what they are doing are free to shoot themselves in the foot by fiddeling with the defaults too! I think this change is very low-risk. And as it is the popular choice, it will see more analysis by the crypto- community, which means earlier warning should it have real (practical) problems. > Milan > p.s. > For people (like me :) who have no easy access to final IEEE documents, here is the > XTS draft which is enough to understand XTS block mode. > http://grouper.ieee.org/groups/1619/email/pdf00086.pdf Hehe, I think I have looked at this one too. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx GnuPG: ID: CB5D9718 FP: 12D6 C03B 1B30 33BB 13CF B774 E35C 5FA1 CB5D 9718 ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
