Question on LUKS master key digest and its effect on security

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

I've been using LUKS with dm-crypt for a while now and have recently 
been trying to learn more about how it works. There's still one aspect 
in LUKS I have not found a simple answer to. That is, is the security 
of my data dependent on the public (visible in the headers) master key 
digest? I've understood that it is derived by PBKDF2 where in LUKS's 
case SHA-1 is the hash used. LuksDump accordingly shows the 160-bit 
digest which, if I again understand correctly, is used to check if the 
supplied key and the master key match. 

Now, the impression I've gathered is that in this case if I were able to 
derive from this digest the original input, I could recover the master 
key and hence decrypt the encrypted data. In other words, the master 
key is secured by the strength of the PBKDF2 procedure, which in this 
case relies on SHA-1. I've been told that SHA-1 is now considered 
broken for all uses except generating pseudo random data, i.e. hashing 
password strings to key bits in cases where the digest is not made 
availabe, i.e. the GnuPG S2K scheme and many similar. I've also gathered 
that even if SHA-1 were not broken, it would provide at max. 80 bits of 
security (due to the birthday paradox) against recovering the input 
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?

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

So my question is, why is having the digest generated by SHA-1 not a 
security concern, i.e. this will not make recovering the key easier 
than brute forcing a high-entropy, user-specified password string or  
AES-128 directly (in case that was used)? If there are actual security 
implications, is it possible to change the hash spec by the user?

Thank you for any comments on this,
and kind regards,
Tero Pesonen
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt


[Index of Archives]     [Device Mapper Devel]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite News]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux