From: "U.Mutlu" <for-gmane@mutluit.com>
To: dm-crypt@saout.de
Subject: Re: [dm-crypt] plain: opening with a wrong password
Date: Thu, 05 Feb 2015 15:04:39 +0100 [thread overview]
Message-ID: <mavt9n$4et$1@ger.gmane.org> (raw)
In-Reply-To: <mavsjs$ntq$1@ger.gmane.org>
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).
cu
Uenal
next prev parent reply other threads:[~2015-02-05 14:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 12:33 [dm-crypt] plain: opening with a wrong password U.Mutlu
2015-02-04 13:02 ` Quentin Lefebvre
2015-02-04 13:30 ` U.Mutlu
2015-02-05 11:54 ` Arno Wagner
2015-02-05 13:53 ` U.Mutlu
2015-02-05 14:04 ` U.Mutlu [this message]
2015-02-05 23:51 ` Arno Wagner
2015-02-06 14:01 ` dennis
2015-02-06 14:19 ` Michael
2015-02-06 14:47 ` U.Mutlu
2015-02-06 18:27 ` Arno Wagner
2015-02-07 17:27 ` dennis
2015-02-07 18:03 ` Heinz Diehl
2015-02-07 23:16 ` Matthias Schniedermeyer
2015-02-08 8:19 ` Heinz Diehl
2015-02-08 9:23 ` Arno Wagner
2015-02-08 9:55 ` Milan Broz
2015-02-08 10:09 ` U.Mutlu
2015-02-08 10:33 ` Milan Broz
2015-02-09 3:13 ` Arno Wagner
2015-02-08 3:07 ` Arno Wagner
2015-02-08 2:59 ` Arno Wagner
2015-02-06 14:04 ` U.Mutlu
2015-02-06 18:20 ` Arno Wagner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='mavt9n$4et$1@ger.gmane.org' \
--to=for-gmane@mutluit.com \
--cc=dm-crypt@saout.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.