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

["U.Mutlu" <for-gmane@mutluit.com>]

Arno Wagner wrote, On 02/06/2015 12:51 AM:
> 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

IMO that's a question of logic:
A security system which stores the password in its header (ie. LUKS)
cannot be secure against another system ("plain") that does nowhere
store the password.
In the case of LUKS the attacker knows more about the system
than in the case of "plain". Ergo "plain" is more secure than LUKS.

LUKS uses a static master key (as does plain). The slot passwords
are for authenticating the access to the filesystem by the
management tool (cryptsetup) only. Ie. the slot passwords have
nothing to do with the encryption.

cu
Uenal