Re: [dm-crypt] plain: opening with a wrong password

[Matthias Schniedermeyer <ms@citd.de>]

On 07.02.2015 19:03, Heinz Diehl wrote:
> On 07.02.2015, dennis@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.

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