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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox