[dm-crypt] plain: opening with a wrong password
ms at citd.de
Sun Feb 8 00:16:24 CET 2015
On 07.02.2015 19:03, Heinz Diehl wrote:
> On 07.02.2015, dennis at basis.uklinux.net 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.
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
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.
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.
More information about the dm-crypt