On 07.02.2015 19:03, Heinz Diehl wrote: > On 07.02.2015, dennis@xxxxxxxxxxxxxxxxx wrote: > > > My conclusion would have been that if the passphrase is > > initially at least as secure as a random key, then hashing can never > > increase security but may decrease it. > > You need something to compare the passphrase to, and that's the hash. > How would you check the validity of the entered passphrase otherwise? > A plain text comparison is obviously impossible. No. With Plain the password can't be verified, the dm-crypt device is setup and if the password was wrong, the "decrypted" device contains garbage. Containers usually have a means to test if the password is correct, plain does not. > An example which at least partially covers the same item is password storing by > netshops, e.g. those who send you the plaintext passphrase when providing your > email after hitting "Forgotten password". A breach into this password database > reveals all passwords in clear text. Therefore, passwords usually are stored as > their hash, and the clear text is deleted right after the hashing. That are > those netshops which will provide a reset link to you after hitting the > "Forgotten password" button, because they only have the hash, which can't be > re-translated into the clear text passphrase. Which is a totally different thing. Here the you tell the gatekeeper your secret password and the gatekeeper will let you through if you satiesfy the rules of the day. The rule usually is "I will let you through, if the hash of the password you provided me is the same one as the one i have on file". But the rules can be pretty much anything, up to "Anybody with any password" if the programmer had a bad day. IOW. The password itself doesn't protect anything, it's the (hopefully) debugged gatekeeper that does the protecting. So if you break the gatekeeper, you can circumvent the password without knowing it. Actually encrypting the data of the user with the password of the user, so you actually needed to password is "uncommon" AFAIK. Whereas in encryption the password itself (with or without hashing and/or decrypting the actual key) is directly used and can't be circumvented to get access to the data. It's somewhat like the PALs with an encrypted firing sequence, the PAL code itself is used in the firing sequence to correctly shape the nuclear material. With a wrong code the weapon will just mis-detonated and not reach criticallity and will hopefully be unusable afterwards. http://en.wikipedia.org/wiki/Permissive_Action_Link Before the encrypted firing sequence you could "just" remove the PAL and use your own detonation mechanism, as the code itself was nothing more like comparing the code to a stored hash and the gatekeeper was the thing that actually pressed the big red button. With an encrypted firing sequence that doesn't work, as you still need the parameters for the correct firing sequence, which hopefully can't be easily reverse engineered. -- Matthias _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
