On Sat, Jan 03, 2015 at 00:18:21 CET, Christian Stadelmann wrote: > Hi > > I find several defaults in cryptsetup are less secure than they can be. Security is not the only goal in such a software. Please do not just state names and numbers, give reasoning that includes how things are used and cite references. > Below I list them with some comments: > > cipher: aes-cbc-essiv (default in plain mode) > There are known attacs against aes-cbc-essiv which lead to using aes-xts > as default cipher in LUKS mode. Is there any reason why it should not be > used in plain mode? Simple: Backwards compatibility. As plain mode does not have a header, this would break old uses. Anybody that wants it can already use XTS. > key size: 256 (default) > For using aes256 (which is the default cipher in LUKS mode) the key size > should be 512 bit since XTS splits the supplied key. The default is AES-128. If you have some insights why/how that is insecure, please cite them. > hash: sha1 (default) > SHA-1 is considered weak for some years, SHA-2 is widely available. Is > there any reason against using SHA-2? Since hashing is only done once > sha512 could be default. Not for this use, see FAQ Item 5.20. > iter-time: 1000 (default) > could be increased. Or it could not. It is a well balanced default, that leads to an unlock time of up to 10 seconds and an unlock fail time of 10 seconds. Increasing it by default would be a problem in many cases. > random number pool: /dev/urandom (default) > this should definitely be `--use-random` as default, you should never > use /dev/urandom for long-term crypto keys. It may result in using > low-entropy keys which obviously must not happen. It might take some > time to gather enough entropy, but that is ok since performance is not > relevant for an operation done once. Additionaly I think it would be > best to disable the option `--use-urandom` completely. No. Really not. There is extensive discussion of this question on the mailing-list. Read that and then come again. > key derivation function: PBKDF2 > PBKDF2 is easy to implement in FPGAs or ASICs which reduces its > strength. It is safe enough for today but scrypt is a good alternative. There is a password-hashing competition going one at this time: https://password-hashing.net/ It would be pretty stupid not waiting for the results. Also, scrypt cancelled its standardization attempt (the IETF RFC-draft expired), so it is not really in a final state. Most of the entries in the competition are also much better than scrypt and it is reasonable to expect that the winners will complete standardization and then can form a solid base for version 2.0 of the LUKS header. > To summarize: Strong crypto is available. It should be default. That reasoning is flawed. The primary requirement for crypto software is usability. Not used crypto can be extremely secure without that helping one bit, as not used software protects noting. Sure, security is a strong second requirement, but you have failed to demonstrate any insecurty that is not trumped by usability. Side note: All these questions have been discussed extensively on the mailing list, and I would say by people that know their stuff. Have you even tried to find out? Barging in here like that with this type of attitude is pretty rude. 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 ---- A good decision is based on knowledge and not on numbers. -- Plato 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
