On Mon, Aug 24, 2015 at 08:18:39 CEST, Milan Broz wrote: > > On 08/23/2015 10:21 PM, Sven Eschenberg wrote: > > Maybe I got a misconception here. > > > > But if I remember correctly: > > > > In case of auth, a collision might get you authed, in LUKS a collission > > gets you past the candidate check, but a mere collision without hitting > > the correct key, results in gibberish during decryption. > > Yes. Maybe this should be added to FAQ... Indeed. It is a less frequently asked question, bit it does get asked from time to time. I will write something. > Just a little bit engineering background to the theory below :) > > The hash algorithms specified in LUKS header is used to: > > 1) underlying PBKDF2 for derivation of keyslot unlocking password > (keyslot is encrypted with the same algorithms as data with this > derived key) > > 2) Decrypted key candidate digest check. I think this has something like 0.25 seconds of PBKDF2 iterations well. > 3) Anti-forensic (AF) LUKS splitter > > (4) the hash used for ESSIV was always SHA256 as a default, this is unrelated > to hash mentioned above and it is already "obsoleted" by using XTS mode where > we do not need ESSIV) > > Just note, for 2) there we have only 20bytes in header for MK digest. > (IOW it was designed for SHA1.) Which is actually an advantage, as the MK may have 256 bits of entropy, this has only has 160. That means even if you can reverse the MK iterations of PBKDF2, you are still short 96 bits. This should probably be kept or even shortened to 128 bits in the next LUKS header version. > This is really not a real problem, because even if you find the collision, > you have wrong key and result is decrypted gibberish (as Sven already said). You could trick things that check for a vcalid key but never decrypt anything. That would be a pretty gross misuse of LUKS, so we do not need to care aboyt it. > And why SHA1 as a default? > Well, it is history and more about user experience trade-off that anything > else. > > - original LUKS implementation had SHA1 hardcoded, old implementation > cannot decrypt anything else (pre 1.1.x versions) > > - in >= 1.1.x the library SHA1 is used and code allows switch to other > hash algorithm (provided by underlying crypto library). > > But because in that time (~2010) most of implementations in stable distro > releases had SHA1 hardcoded, it would make LUKS incompatible. > (Moreover using SHA1 is still not a problem there, otherwise security > aspects would have priority even if it means breaking compatibility.) > > Today, it is probably possible to change hash default without a big hassle. > But we have more serious problem here: PBKDF2, which is no longer the best > KDF we can use here. While the winner of the password hashing competition is known, they ares till finalizing it, as far as I remember. This thing is much more advanced than PBKDF2. > So the plan is to introduce slightly modified LUKS2 header that > allows specifying another KDF (probably per-slot) and some > other things and this would be the best time to switch the hash default > as well. Indeed. > (Despite SHA1 is not problematic for this use case, it will be soon banned > in some environments. And there is a compile switch to change default for > years, so distros can change it.) I think that is the main reason for eventually changing it/making it configurable: Users that cannot use SHA1 for any purpose due an organizational ban. This should also get an FAQ item along the lines "Help, I am forbidden to use SHA1!". > There will be some experimental branch in distro for prototyping this > (heading to cryptsetup 2.x & LUKS2. Ecellent. If you want feedback on the new header format and things, please let me know. As the original design of the header wisely includes a version number, compatibility should not be an issue though. Regards, 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
