Tero Pesonen wrote: > from the digest output. Now if it is true that the LUKS master key > digest is truly the SHA-1 derived digest of the master key, then to me > it seems the LUKS-dm-crypt security relies on this weak point, not on > the AES-128, for example. I guess I must be wrong here? Note that hash verification is not applied directly to master key, but to result of PBKDF2 (with DigestKey iterations) where master key is only on its input. See LUKS_verify_master_key() in code to verify that. Please read archive of this list, explaining that sha-1 is not problem is here http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/3300 > I tried, nevertheless, to create a new LUKS partition with a different > hash spec, but despite what I provided for the --hash=HASH (e.g. > SHA256) it always created a partition with hash spec SHA1 (and hence a > 20 HEX chars long digest.) Yes it was hardcoded to use sha1. But it is no longer true anyway. Using another hash (all algorithms provided by libgcrypt) is already implemented in devel code. There is only one 20 bytes in LUKS header for digest verification, so final verification of digest uses only first 160bits, but it is not a security problem. (And I'll release testing version soon with this code.) Milan _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
