[dm-crypt] security: improve defaults

Sven Eschenberg sven at whgl.uni-frankfurt.de
Sun Jan 4 02:59:45 CET 2015

On Sat, January 3, 2015 00:18, Christian Stadelmann wrote:
> 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.

> 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.

> 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.)

> 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.

> 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.

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.

> 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?

> To summarize: Strong crypto is available. It should be default.
> Regards
> Chris



More information about the dm-crypt mailing list