On Wed, Nov 18, 2009 at 12:20:05PM +0100, Milan Broz wrote: > On 11/18/2009 11:25 AM, Arno Wagner wrote: > > I am not sure this really is a security issue. It may confuse users, > > but they will still be secure. Most probably use defaults anyways. > > Or distro installation defaults.. e.g. Fedora12 installer switched > to AES in XTS mode (with 512bit - so it uses AES-256)... > > But if we change this, I propose to make aes-cbc-essiv:sha256 > > the default for plain dm-crypt and to increase LUKS key length > > to 256 bits as well. The performance loss is apparently very > > small (10% or so). > > I thought about default change for LUKS in cryptsetup 1.1.0, but... > > For default LUKS cipher: > > I agree with switching default to 256bits for LUKS) > (aes-cbc-essiv:sha256 is already default), just some ideas > > - some discussions about recent theoretic attacks against AES-256 > (related key), maybe some people want use AES-128... Last I read was that they have something of similar strength for AES-128 now. I think the currenct worst case is that AES-256 drops down to the security level of AES-128. IS somebody really wants AES--128, they can still override the defaults. > - for recent kernel, XTS mode is more appropriate, but it cause > backward incompatibility (XTS is not available in old kernels) > (IOW default to aes-xts-plain ?) > > (Ignoring the 32-only plain IV problem here, because XTS suggested use > is for volumes <1TB. I have already patch for plain64 dm-crypt IV btw, > just it got lost in Alasdair's upstream patch queue.) Hmm. Well, XTS has more reputable support as essiv (which was done by Clemens himself), and the provision against doing your own crypto may apply. Personally, I see nothing wrong with essiv, and it cannot really be less secure thain plain CBC. > For default LUKS header hash: > > - default is SHA1 > > switching to another (probably SHA-256?) means complete incompatibility > with all cryptsetup <1.1.x, this need some time when all most distros > use new cryptsetup. > No need to hurry, there is no problem with SHA1 in this application > of hash function. I completely agree. The current attacks on sha1 do not even suggest a possible attack against its use here. IN addition, SHA256 is more of a stopgap, so if no emergency arises (SHA1 easily reversible or the like), it is probably bets to wait for the outcome of NIST's hash challenge for a possible replacement. > For plain cipher mode: > > I am not sure if it is good idea to change default, if anyone using > default in crypttab, it cause serious incompatibility with possible > data loss. > But I agree that aes-cbc-essiv:sha256 is better default here. > > Can distro maintainers think about this? There is not problem > for encryption of swap using random key. > Maybe it will need some warning during upgrade if there is such plain > volume in crypttab. I think an appropriate warning on packet upgrade is needed (hence the distro's job, a clear warning in README/INSTALL/CHANGELOG is certainly a good idea). Crypttab can be adjusted to list a different cipher per volume after all, it just has to be done. It would also be possible to ask the user on packet upgrade whether all old entries without cipher specification should be marked with the old default to keep them going. > Please correct me if I am wrong:-) > > So, if there are no objections, I'll change default key size for LUKS to > 256bits in final cryptsetup 1.1.0 release. The plain default is still open > question. Sounds reasonable. 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
