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

Arno Wagner arno at wagner.name
Fri Feb 6 00:51:35 CET 2015

On Thu, Feb 05, 2015 at 15:04:39 CET, U.Mutlu wrote:
> U.Mutlu wrote, On 02/05/2015 02:53 PM:
> >Arno Wagner wrote, On 02/05/2015 12:54 PM:
> >>On Wed, Feb 04, 2015 at 14:30:17 CET, U.Mutlu wrote:
> >>>Quentin Lefebvre wrote, On 02/04/2015 02:02 PM:
> >>>>Hi,
> >>>>
> >>>>Le 04/02/2015 13:33, U.Mutlu a écrit :
> >>>>>Hi,
> >>>>>what happens if an encrypted filesystem (plain, no LUKS)
> >>>>>next time is opened accidently with a wrong password,
> >>>>>and new data written to it? Will the filesystem then become
> >>>>>damaged/unusable?
> >>>>
> >>>>What typically happens when you use a wrong password is that the
> >>>>cryptsetup create/open command is indeed successful, but mounting your
> >>>>partition will fail (because the filesystem is not detected).  So you
> >>>>have few chance to accidentally damage a filesystem, even in plain
> >>>>mode.
> >>>
> >>>I tried this out now, and indeed that's cool!
> >>>Thank you for this useful tip, it spares me to study further
> >>>also the LUKS stuff, as plain is IMHO sufficient for my needs.
> >>>The main drawback with plain seems to be that one cannot change
> >>>the password, instead one needs to re-enrcrypt into a new file/device.
> >>
> >>That, you have only one password, and you do not get some
> >>additional protection for weak passwords from salting and
> >>iteration. With a good, passphease plain is about as secure
> >>as LUKS, namely not breakable. (See FAQ item 5.1 for details
> >>of what "good" means.)
> >>
> >>Arno
> >
> >Yes, and one better should create a password by using a password hasher like
> >the following:
> >$ echo mypassword | hashalot -x -s mysalt sha256
> >5d9de7f56a469782ff8a6be363418f62d6f93e33c3adb5c216e7e9c2f9947240
> >and pass the result to the target (of course using something else for
> >"mypassword" and "mysalt").
> Oh, I forgot to mention: with such a strong password
> "plain" is IMHO more secure than "luks" b/c plain offers
> no attack vectors (ie. metadata headers).

Actually, it is not. I do disagree on the hashalot approach
as well. If your passphrase is weak enough that a dictionary
attack has a reasonable success of working (and a dictionary
attack is the only thing the salt that hashalot adds helps 
against), then you are pretty deep in insecure territory and
_need_ the hash iteration that LUKS provides, but which is 
missing from both plain and hashalot.

Aso, you can simulate a salt directly with plain as follows: 
Just give your passphrase and append the known salt. That is 
about as secure as the more complicated approach with hashalot.  

The other thing is that the LUKS metadata-headers do not make
attacks any easier. They do _not_ provide "attack vectors".
Salts are per definition not secret. If you make the salt 
secret, you are doing it wrong. Instead append the secret to 
the passphrase and add a non-secret salt. The only other thing
an attacker gets is the iteration count. That one does not
add a lot of protection if unknown (after all, the iteration 
time is known and likely also the CPU it was done on), but
its needed for deriving the key in legitimate unlocks.

Please do not spread unsubstantiated rumors. It is hard enough
these days for non-experts to decide what crypto to trust
and what not. Rumors of the kind "metadata headers offer
attack vectors" make this even worse.

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at wagner.name
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

More information about the dm-crypt mailing list