security: improve defaults
Hi
I find several defaults in cryptsetup are less secure than they can be. 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?
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.
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.
iter-time: 1000 (default)
could be increased.
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.
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.
To summarize: Strong crypto is available. It should be default.
Regards
Chris
Quoted 3 lines · Christian Stadelmann
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.
Quoted 6 lines
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.
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 2 lines
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.
Quoted 7 lines
random number pool:
/dev/urandom(default)
this should definitely be--use-randomas default, you should never use/dev/urandomfor 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-urandomcompletely.
No. Really not. There is extensive discussion of this question on the mailing-list. Read that and then come again.
Quoted 3 lines
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:
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.
Quoted 1 line
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
Signature · 7 lines
Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: [email protected] 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
Quoted 10 lines · Arno Wagner
Quoted 4 lines · Christian Stadelmann
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.
seconded; I rely on this -- please don't change this :-)
Christian: anyone who is using dm-crypt in plain mode *already* knows what he is doing. If they don't, they should not be using plain mode. There is no need for you or me to worry about them, in my opinion.
Adding just fey my notes...
Quoted 10 lines · Arno Wagner
Quoted 4 lines · Christian Stadelmann
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.
BTW XTS has own flaws, the main problem is that granularity of a change (small plaintext change propagates only to one cipher block in ciphertext). But unfortunately we do not have better mode (for the default). Very nice comments are in
http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/comments/XTS/collected_XTS_comments.pdf
And definitely the CBC should be phased out but, for plain mode the compatibility is the main problem - you will break many people systems when switching default.
Quoted 6 lines
Quoted 3 lines
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.
Fully agree.
Quoted 6 lines
Quoted 4 lines
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.
This will change once other LUKS header get new major version (probably together with PBKDF change, see below). There is no problem with SHA1 here but it will save many these useless "SHA1" discussions at least ...
Quoted 7 lines
Quoted 3 lines
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.
Yes, 1 second is a nice balanced default, if you are unlocking the last keyslot and all slots are used, you have 8 seconds unlocking time! Actually others often request to decrease this default ;-)
Quoted 10 lines
Quoted 7 lines
random number pool:
/dev/urandom(default)
this should definitely be--use-randomas default, you should never use/dev/urandomfor 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-urandomcompletely.No. Really not. There is extensive discussion of this question on the mailing-list. Read that and then come again.
The same story as SHA1... I already planned to switch upstream to /dev/random as a default just to stop wasting time on this issue.
Please read the discussions, it is not as simple as it seems. Let's start with http://www.2uo.de/myths-about-urandom/
We should care more about proper entropy to initially seed RNG. If you think you have a problem, install some external device seeding your RNG.
Quoted 8 lines
Quoted 3 lines
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:
Quoted 8 lines
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.
I can promise that LUKS will be one of the first users of PHC output. I already spent a lot of time playing with these hasning functions so no need to worry:-)
There is the excellent yescrypt as a direct evolution to scrypt as one of the 2nd round candidate.
But really, nobody will use it now for production when there is no proper analysis of these algorithms and candidates are not yet even chosen.
And one note to PBKDF2/LUKS:
Yes, PBKDF2 itself can run very fast on GPU/ASIC/FPGA but did you try LUKS? The AF filter spreads out keyslot to quite large sector area, and you must have this area in memory to perform attack. Nice side effect which complicates LUKS attack on these platforms.
Quoted 9 lines
Quoted 2 lines
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.
Fully agree. Cryptsetup allows to configure crypto according to your needs. If your analysis says you need something better than default, just use it! But forcing other users to use "stronger" crypto could cause exactly opposite - incompatible containers which cannot be opened on older system, slow unlocking, ...
Many users will stop to use it once this happens. So it is about finding usability tradeoff here.
Milan
Quoted 9 lines · Christian Stadelmann
Hi
I find several defaults in cryptsetup are less secure than they can be. 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?
As others stated, backward compatibility.
Quoted 4 lines
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.
There's no AES for >128 bit - Well not for block sizes beyond 128 bit and key lengths beyond 256 bit. You certainly would want to adhere standards for defaults.
Quoted 5 lines
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.
SHA-1 is not per se weak. The way it is used in LUKS does not expose the problem (which you don't properly refer to, btw.)
Quoted 3 lines
iter-time: 1000 (default)
could be increased.
Could be, defaults should be sensitive though and if you don't mind unlock times of 30 seconds you are free to change it.
Quoted 8 lines
random number pool:
/dev/urandom(default)
this should definitely be--use-randomas default, you should never use/dev/urandomfor 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-urandomcompletely.
The default is set at compile time - The default is chosen by yourt distributor (or yourself) and does depend on your targeted platform. There have been numerous lengthy discussions on this.
Quoted 4 lines
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.
Is it?
Quoted 5 lines
To summarize: Strong crypto is available. It should be default.
Regards
Chris
Regards
-Sven