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

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

[U.Mutlu]

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?

I didn't try this out, but I know the create/open command accepts
any password for an already existing encrypted filesystem
since no metadata is stored with such a "plain" volume, right?

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

[Quentin Lefebvre]

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 didn't try this out, but I know the create/open command accepts
> any password for an already existing encrypted filesystem
> since no metadata is stored with such a "plain" volume, right?

Right, but this does not mean that data will look meaningful.

Best,
Quentin

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

[U.Mutlu]

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.

cu
Uenal

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

[Arno Wagner]

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

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

[U.Mutlu]

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").

cu
Uenal

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

[U.Mutlu]

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

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

[Arno Wagner]

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

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

[dennis]

On Fri, Feb 06, 2015 at 12:51:35AM +0100, Arno Wagner wrote:
> 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.
>
>...
>
> 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.

Count me among the non-experts. I have two questions. (a) Wouldn't
metadata headers incur a loss of plausible deniablity compared to
plain mode, especially when an encrypted filesystem image is stored as
a single file on backup media or in the backing file for a loopback
device? (b) Assuming a secure passphrase, wouldn't plain mode be more
secure than luks against possible vulnerabilities in the hashing
algorithm that may be discovered in the future?

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

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1542 bytes --]

If you are concerned about the header, you could use Luks with a  
detached header. This way you have the advantages of Luks and you can  
store the header separate from the encrypted container.

Quoting dennis@basis.uklinux.net:

> On Fri, Feb 06, 2015 at 12:51:35AM +0100, Arno Wagner wrote:
>> 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.
>>
>> ...
>>
>> 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.
>
> Count me among the non-experts. I have two questions. (a) Wouldn't
> metadata headers incur a loss of plausible deniablity compared to
> plain mode, especially when an encrypted filesystem image is stored as
> a single file on backup media or in the backing file for a loopback
> device? (b) Assuming a secure passphrase, wouldn't plain mode be more
> secure than luks against possible vulnerabilities in the hashing
> algorithm that may be discovered in the future?
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt


-- 
Regards,
Michael

https://skrilnetz.net

[-- Attachment #2: PGP Public Key --]
[-- Type: application/pgp-keys, Size: 1718 bytes --]

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

[U.Mutlu]

Michael wrote, On 02/06/2015 03:19 PM:
> If you are concerned about the header, you could use Luks with a detached
> header. This way you have the advantages of Luks and you can store the header
> separate from the encrypted container.

Beware: there are some warnings in the documentation @
https://code.google.com/p/cryptsetup/wiki/Cryptsetup140
"
WARNING: There is no possible check that specified ciphertext device matches 
detached on-disk header.
Use with care, it can destroy your data in case of a mistake.

WARNING: Storing LUKS header in a file means that anti-forensic splitter 
cannot properly work
(there is filesystem allocation layer between header and disk)."

cu
Uenal

> Quoting dennis@basis.uklinux.net:
>
>> On Fri, Feb 06, 2015 at 12:51:35AM +0100, Arno Wagner wrote:
>>> 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.
>>>
>>> ...
>>>
>>> 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.
>>
>> Count me among the non-experts. I have two questions. (a) Wouldn't
>> metadata headers incur a loss of plausible deniablity compared to
>> plain mode, especially when an encrypted filesystem image is stored as
>> a single file on backup media or in the backing file for a loopback
>> device? (b) Assuming a secure passphrase, wouldn't plain mode be more
>> secure than luks against possible vulnerabilities in the hashing
>> algorithm that may be discovered in the future?
>> _______________________________________________

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

[Arno Wagner]

On Fri, Feb 06, 2015 at 15:01:40 CET, dennis@basis.uklinux.net wrote:
> On Fri, Feb 06, 2015 at 12:51:35AM +0100, Arno Wagner wrote:
> > 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.
> >
> >...
> >
> > 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.
> 
> Count me among the non-experts. I have two questions. (a) Wouldn't
> metadata headers incur a loss of plausible deniablity compared to
> plain mode, especially when an encrypted filesystem image is stored as
> a single file on backup media or in the backing file for a loopback
> device? 

In theory, yes, in practice no. See FAQ Item 5.18. Plausible 
deniability is a fantasy that does not hold up in reality. 
See also http://xkcd.com/538/. This really _is_ accurate.

>(b) Assuming a secure passphrase, wouldn't plain mode be more
> secure than luks against possible vulnerabilities in the hashing
> algorithm that may be discovered in the future?

No. First, plain mode also hashes. And second, basically all
potential vulnerabilities of modern hash functions (collisions,
reversing) do not apply to the use as pasword-hashing functions. 
You can hash passwords with MD5 and be perfectly secure, while MD5
is fully broken for things like signing.

The only problem is a (very slow) convergence towards half the 
bits in iterated hashing, but PBKDF2 fixes that.

Gr"usse,
Arno

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

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

[dennis]

On Fri, Feb 06, 2015 at 07:27:29PM +0100, Arno Wagner wrote:
> >(b) Assuming a secure passphrase, wouldn't plain mode be more
> > secure than luks against possible vulnerabilities in the hashing
> > algorithm that may be discovered in the future?
> 
> No. First, plain mode also hashes. And second, basically all
> potential vulnerabilities of modern hash functions (collisions,
> reversing) do not apply to the use as pasword-hashing functions. 
> You can hash passwords with MD5 and be perfectly secure, while MD5
> is fully broken for things like signing.

Thank you for answering my questions. I take your point about
plausible deniability, but your remarks about hashing have raised
further questions for me. I had been given to understand that
passphrase hashing makes a dictionary attack more costly or time
consuming by forcing the attacker to evaluate the hash function for
each passphrase attempted, and I have just checked the FAQ for
confirmation. It would seem to follow that a hash algorithm
sufficiently prone to collisions would diminish security by not taking
full advantage of the available key space, possibly to the point of
making a well informed search of the key space more practical than a
dictionary attack. In the degenerate case of a totally stupid hash
algorithm that hashes every passphrase to exactly the same key, the
attacker need only try that particular key and not even evaluate the
hash function. In a less extreme case where the algorithm maps low
entropy passphrases to some keys with higher probability than others,
some of the attacker's work is done for him if he starts with the more
probable keys. 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. If this is a misconception, can
you please correct it?

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

[Heinz Diehl]

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.

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.

It's not only a problem of "security", but feasibility.

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

[Matthias Schniedermeyer]

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

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

[Heinz Diehl]

On 08.02.2015, Matthias Schniedermeyer wrote: 

> > 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.
 
> 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.

I tried to keep it simple in my example. Although you're (of course) right, I
didn't write about "plain encryption" or "plain dmcrypt", but plain text
comparison, in order to explain why there is the need for e.g. a hash.
As you point out, with plain dmcrypt the only possibility is actually
using the password and checking if the "decrypted" data based on it makes any sense.

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

[Arno Wagner]

On Sun, Feb 08, 2015 at 09:19:54 CET, Heinz Diehl wrote:
> On 08.02.2015, Matthias Schniedermeyer wrote: 
> 
> > > 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.
>  
> > 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.
> 
> I tried to keep it simple in my example. Although you're (of course) right, I
> didn't write about "plain encryption" or "plain dmcrypt", but plain text
> comparison, in order to explain why there is the need for e.g. a hash.
> As you point out, with plain dmcrypt the only possibility is actually
> using the password and checking if the "decrypted" data based on it 
> makes any sense.

Form a purely practical perspective, the difference usually negligible.
Wile plain dm-crypt mounting fails at the mount-stage due to wrong
filesystem signatures, LUKS mounting fails at the decrypt stage. 

From an attacker's perspecive, the difference is also small, except
that all the iteration in LUKS adds a massive amount of computational
effort. The data in the LUKS header does not help the attacker at all.
It does take a look at the details (as so often in crypto protocols)
to see that though.

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

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

[Milan Broz]

On 02/08/2015 10:23 AM, Arno Wagner wrote:
> On Sun, Feb 08, 2015 at 09:19:54 CET, Heinz Diehl wrote:

> Form a purely practical perspective, the difference usually negligible.
> Wile plain dm-crypt mounting fails at the mount-stage due to wrong
> filesystem signatures, LUKS mounting fails at the decrypt stage. 

Beware, there are some combinations of the encryption mode + IV which decrypts
the first block correctly in both cases, so fs returns correct signature
but fs is obviously corrupted... if you are not lucky, fsck will run
and breaks the fs irrecoverably... 

This cannot happen with LUKS.

See here that the ext3 device created with ESSIV still have visible signature
with plain IV:

# echo "password" | cryptsetup create -c aes-cbc-essiv:sha256 -s 256 x /dev/sdb
# mkfs -t ext3 -q /dev/mapper/x
# blkid -p /dev/mapper/x
/dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" 

... use fs
# cryptsetup close x

And now thy mistake with plain IV:

# echo "password" | cryptsetup create -c aes-cbc-plain -s 256 x /dev/sdb
# blkid -p /dev/mapper/x
/dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" 

# mount /dev/mapper/x /mnt/tst
mount: wrong fs type, bad option, bad superblock on /dev/mapper/x,
       missing codepage or helper program, or other error
...

DO NOT use plain mode if you are not sure what you are doing. Really.

There is a detached LUKS header which is better, the issues I mentioned in man
about detached header page are side problems, nothing serious for most users.
(But obviously depends on your threat model.)

Milan

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

[U.Mutlu]

Milan Broz wrote, On 02/08/2015 10:55 AM:
> On 02/08/2015 10:23 AM, Arno Wagner wrote:
>> On Sun, Feb 08, 2015 at 09:19:54 CET, Heinz Diehl wrote:
>
>> Form a purely practical perspective, the difference usually negligible.
>> Wile plain dm-crypt mounting fails at the mount-stage due to wrong
>> filesystem signatures, LUKS mounting fails at the decrypt stage.
>
> Beware, there are some combinations of the encryption mode + IV which decrypts
> the first block correctly in both cases, so fs returns correct signature
> but fs is obviously corrupted... if you are not lucky, fsck will run
> and breaks the fs irrecoverably...
>
> This cannot happen with LUKS.
>
> See here that the ext3 device created with ESSIV still have visible signature
> with plain IV:
>
> # echo "password" | cryptsetup create -c aes-cbc-essiv:sha256 -s 256 x /dev/sdb
> # mkfs -t ext3 -q /dev/mapper/x
> # blkid -p /dev/mapper/x
> /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem"
>
> ... use fs
> # cryptsetup close x
>
> And now thy mistake with plain IV:
>
> # echo "password" | cryptsetup create -c aes-cbc-plain -s 256 x /dev/sdb
> # blkid -p /dev/mapper/x
> /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem"
>
> # mount /dev/mapper/x /mnt/tst
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/x,
>         missing codepage or helper program, or other error
> ...
>
> DO NOT use plain mode if you are not sure what you are doing. Really.
>
> There is a detached LUKS header which is better, the issues I mentioned in man
> about detached header page are side problems, nothing serious for most users.
> (But obviously depends on your threat model.)
>
> Milan

But isn't it just saying that the mount cannot be done
because something is wrong, ie. wrong/incomplete cipher param was given?

What happens if you repeat the whole with the correct params?

And, should one not use "/dev/sdb1" etc. instead of "/dev/sdb"?

-- 
cu
Uenal

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

[Milan Broz]

On 02/08/2015 11:09 AM, U.Mutlu wrote:

>> And now thy mistake with plain IV:
>>
>> # echo "password" | cryptsetup create -c aes-cbc-plain -s 256 x /dev/sdb
>> # blkid -p /dev/mapper/x
>> /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem"
>>
>> # mount /dev/mapper/x /mnt/tst
>> mount: wrong fs type, bad option, bad superblock on /dev/mapper/x,
>>         missing codepage or helper program, or other error
>> ...
>>
>> DO NOT use plain mode if you are not sure what you are doing. Really.

> But isn't it just saying that the mount cannot be done
> because something is wrong, ie. wrong/incomplete cipher param was given?

For this particular case, yes. But no idea what happen if you try to run fsck
or other tool.

> What happens if you repeat the whole with the correct params?

Depends if there were write IO to that wrongly mapped device and what
these writes destroyed.

The whole point of this exercise is to note that you must use and
remember correct parameters if using plain mode, not only password.

> And, should one not use "/dev/sdb1" etc. instead of "/dev/sdb"?

No. Partition table is optional and it is not used on this disk.

Milan

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

[Arno Wagner]

On Sun, Feb 08, 2015 at 10:55:35 CET, Milan Broz wrote:
> On 02/08/2015 10:23 AM, Arno Wagner wrote:
> > On Sun, Feb 08, 2015 at 09:19:54 CET, Heinz Diehl wrote:
> 
> > Form a purely practical perspective, the difference usually negligible.
> > Wile plain dm-crypt mounting fails at the mount-stage due to wrong
> > filesystem signatures, LUKS mounting fails at the decrypt stage. 
> 
> Beware, there are some combinations of the encryption mode + IV which decrypts
> the first block correctly in both cases, so fs returns correct signature
> but fs is obviously corrupted... if you are not lucky, fsck will run
> and breaks the fs irrecoverably... 

Indeed. My comments only apply to wrong key, they do _not_ apply
to wrong other parameters!
 
> This cannot happen with LUKS.
> 
> See here that the ext3 device created with ESSIV still have visible signature
> with plain IV:
> 
> # echo "password" | cryptsetup create -c aes-cbc-essiv:sha256 -s 256 x /dev/sdb
> # mkfs -t ext3 -q /dev/mapper/x
> # blkid -p /dev/mapper/x
> /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" 
> 
> ... use fs
> # cryptsetup close x
> 
> And now thy mistake with plain IV:
> 
> # echo "password" | cryptsetup create -c aes-cbc-plain -s 256 x /dev/sdb
> # blkid -p /dev/mapper/x
> /dev/mapper/x: UUID="f46ba5d8-8c26-4589-ac09-cb0829f2804f" SEC_TYPE="ext2" VERSION="1.0" TYPE="ext3" USAGE="filesystem" 
> 
> # mount /dev/mapper/x /mnt/tst
> mount: wrong fs type, bad option, bad superblock on /dev/mapper/x,
>        missing codepage or helper program, or other error
> ...
> 
> DO NOT use plain mode if you are not sure what you are doing. Really.

I second that! 

Arno

> There is a detached LUKS header which is better, the issues I mentioned in
> man about detached header page are side problems, nothing serious for most
> users.  (But obviously depends on your threat model.)

> 
> Milan
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

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

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

[Arno Wagner]

On Sat, Feb 07, 2015 at 19:03:56 CET, 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.

Note that "compare" here may also mean things like "decrypt something
with it and see whether that has some expected checksum" and even
more complex ways of "comparing". The base case of storing a password
in hashed form, as for example, the unix /etc/passwd file is only 
one form of doing it, namely the form necessary when doing 
authentication. Authetication delivers 1 bit as result, a 1 for
"yes, this is the guy he claime to be" and a 0 for the other case.

LUKS for example does not do authentication, but key protection. 
That is different. Its result is a key used for encryption 
and hence the result is, for example, 128 bit or 256 bit.

Hence LUKS does not store any hashed passwords. Instead it tries to 
reconstruct the master key from the anti-forensic stripes and
then checks whether this really is the master-key, again in a way
indirect enough that the stored information that in the end is 
compared against does not help to find the master key.

Gr"usse,
Arno

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

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

[Arno Wagner]

On Sat, Feb 07, 2015 at 18:27:48 CET, dennis@basis.uklinux.net wrote:
> On Fri, Feb 06, 2015 at 07:27:29PM +0100, Arno Wagner wrote:
> > >(b) Assuming a secure passphrase, wouldn't plain mode be more
> > > secure than luks against possible vulnerabilities in the hashing
> > > algorithm that may be discovered in the future?
> > 
> > No. First, plain mode also hashes. And second, basically all
> > potential vulnerabilities of modern hash functions (collisions,
> > reversing) do not apply to the use as pasword-hashing functions. 
> > You can hash passwords with MD5 and be perfectly secure, while MD5
> > is fully broken for things like signing.
> 
> Thank you for answering my questions. I take your point about
> plausible deniability, but your remarks about hashing have raised
> further questions for me. I had been given to understand that
> passphrase hashing makes a dictionary attack more costly or time
> consuming by forcing the attacker to evaluate the hash function for
> each passphrase attempted, and I have just checked the FAQ for
> confirmation. 

That is not what the hashing of the plain-text password is for.
You are confusing several things here:

1. Password hashing from ASCII string to binary key
2. Salting
3. Iterated hashing


The 1. step sinply serves to transform the entropy of your 
password/passphrase into something that can be fed as key to a
cipher. The cipher takes 128 bit or 256 bit of key material,
ideally with about 128 bit or 256 bit of entropy.
Your passphrase, on the other hand, may be, say 10...50 
ascii characters, but on a bit-level ASCII has low entropy.
If it is, for example, an anglish sentence, you get only
about 0.2...0.3 bit/bit of entropy in it. And if you just cut 
it down to, say, 128 bit, you end up with a 26 bit key for
the cipher, which is trivially broken.

Hashing with a crypto hash is the solution. The initial hash  
compresses the passphrase into a concentrated form that is all 
binary and has the same entropy as the input up to the maximum 
possible. You lose a tiny bit (0.00...001 bits or so) due to hash
collisions, but they are so rare as not to matter. If your 
passphrase is shorter, the hash still makes you an all binary 
key with the entropy nicely dirtributed over all bits.

Ok, so what is salting for? Salting meians instead of
hash(password) you do hash(pasword+salt) with the salt random,
non-secret and appended to the password. This servers to
defeat dictionary attacks. A dictionary attack takes 
a large table of potentiall hasswords, and stores all
hashes of these in a table sorted by the hash valye.
This means given a hash, you can retrieve the password
(if it was in the initial table size) in O(log(tablesize))
time by binary search. That is exceptionally fast and
can be done en-masse. The only potential problem is the 
table size. So what salting does is that for each potential
salt valyue, you need a separate table. That makes pre-
computing the table and re-using the table for several 
attacks infeasible, and you are down to directly trying
all hash(password+salt) for the known salt. Note that for
attacking a single password, these tables (called "rainbow
tables) do not help you. In fact, making a rainbow table
iis more effort than the direct attack (called "brute force"),
as you need to sort and store the table. But if you were
to attack, say, 250 Million or 8 Billion passwords, then
rainbow tables make this possible while individual attacks
would be infeasible or exeptionally expensive.

And then we have the hash iteration. The has iteration
served to drive the cost of each individual password
try up. So for brute force, you try a lot of hash(password).
If you hash is, say, a single sha256, each step takes, say
2us. That means you can try something like 500'000 passwords
per sesond on a typical PC on each CPU core. What iteration 
does is to use hash(hash(.....hash(password)...)) instead,
with LUKS so that it takes 1 second of iteration on container
creation. Suddenly, each attack try takes 1 second on said
srtandard PC CPU and the attacker can try 1 password per
second. Here you has a small entopy loss in each iteration,
dure to collisions. Modern hash functions have very few
collisions, so for iteration couns of a few million these
do not matter at all, but just to be safe, iteration is not
done directly, but via PBKDF2, that incorporates salting and
hashing in such a way that the entropy loss is prevented.

Of course, there is still the problem that specialized hardware
and garphics cards can hash faster. This is currently in the
process of being solved by the "Password Hashing Competition"
   https://password-hashing.net/
The result will likely be a memory-hard password hashing function,
that iterates in such a way that it needs a specific amount of 
memory (e.g. 1GB would be a sensible value on a PC) in order
to have normal speed and will suffer exponential speed-down if
less memory is available. Graphisc cards usually only have 32...64k
of fast memory per "CPU" in there and will not be faster for
these functions. FPGAS and other ASICS suffer the same problem: 
you cannot put a lot of memory in them. 


> It would seem to follow that a hash algorithm
> sufficiently prone to collisions would diminish security by not taking
> full advantage of the available key space, possibly to the point of
> making a well informed search of the key space more practical than a
> dictionary attack. 

Indeed. That is why a crypto-hash is used. They are not probe to
collisions at all, as that is one of their central design criteria.
Even broken algorithms like MD5 do not have excessive collisions,
but they have some that are (relatively) easy to find. The worst
for MD5 are that you can cleverly manipulate the plain-text in
order to get a different one with the same hash-value. This
allows you to change an X.509 certificate. Note that this is
not easy to do and only some changes are possible, but in some
cases you can, for example, turn an ordinary certificate into
a CA certificate: http://www.wired.com/2008/12/berlin/

Note that this requires you to have the plain-text that was hashed
and hence does not impact password hashing at all.

> In the degenerate case of a totally stupid hash
> algorithm that hashes every passphrase to exactly the same key, the
> attacker need only try that particular key and not even evaluate the
> hash function. In a less extreme case where the algorithm maps low
> entropy passphrases to some keys with higher probability than others,
> some of the attacker's work is done for him if he starts with the more
> probable keys. 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. If this is a misconception, can
> you please correct it?

Indeed. You are thinking of hash functions, but not hash functions as
used in crypto. For convenience, the term "crypto" is dropped from
"crypto-hash" when discussing cryptographic applications. This is
admittedly a constant source of confusion for newcomers until somebody
explains it to them. When discussing anything crypto, you say
"hash-function" for cryoptographic hash functions and you say
"conventional hash function" when you mean non-cryptographic ones.

For a conventional hash function, such as used in hash-tables, 
collisions are a nuisance, but unavoidable in most cases. Hence 
you try to avoid them, but not very hard. Although modern 
variants like SIP-hash or SpookyHash are pretty good at it. 

Cryptograohic hash functions, on the other hand, critically need
high collision resistance (i.e. rare and hard to find collisions 
even if somebody actively searches for them) and hence are entirely 
different birds. They basically do the same as normal hashes, but 
with some very strict additional requirements, among them collisions 
resistance, hard to invert, etc.

Now, why not just use only crypto-hashes, also in hash-tables?
Simple: Crypoto hashes would work well in that application, but 
they are much slower than conventional hashes and much more 
complex to implement. Hence they are used only in special cases 
for hash-tables.

I hope this clears things up a bit.

Gr"usse,
Arno

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

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

[U.Mutlu]

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

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

[Arno Wagner]

On Fri, Feb 06, 2015 at 15:04:25 CET, U.Mutlu wrote:
[...]
> 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.

That is an argument from information-theoretical security. 
In this realm, plain _does_ store the key with the encrypted
data, unless that has no structure at all. Information-theoretical
analysis is nice theoretically, but basically irrelevant for 
the real world. This argument is also presented in any good
course on introduction to cryptography. 

> 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.

Sorry, but wrong, see above.

> 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.

Seriously? Have you even looked at the spec or at the definition 
of terms like "authentication"? Plese stop discussion things you
clearly do not understand.

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