[dm-crypt] question regarding Sha1 and 512 bit key xts mode

[dm-crypt] question regarding Sha1 and 512 bit key xts mode

[anderson jackson]

In the faq it is said that the use of sha1 for the purpose used in Luks is
valid because it is not the cryptographic feature that is used but instead the
time delay for retreaving the master key. 

However is this really the case? The output of Sha1 is a 160 bit string.
A password is iterated using PBKDF2(with sha1). But can't I just use all the
possible sha1 values to decrypt the master key and validate it with the master
key checksum? Does this not effectively reduce the possible passwords for an
AES 256 bit volume to a password of 160 bit length?

Kind regards,








____________________________________________________________
South Africas premier free email service - www.webmail.co.za 

Slim now! Pay later! http://clients.wm.co.za/20086125/default.htm

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Arno Wagner]

On Wed, Dec 11, 2013 at 17:31:13 CET, anderson jackson wrote:
> In the faq it is said that the use of sha1 for the purpose used in Luks is
> valid because it is not the cryptographic feature that is used but instead
> the time delay for retreaving the master key.

No, that is not the statement. The statement is that collision attacks
(the SHA1-weakness) are irrelevant for password hasing.
 
> However is this really the case? The output of Sha1 is a 160 bit string. 
> A password is iterated using PBKDF2(with sha1).  But can't I just use all
> the possible sha1 values to decrypt the master key and validate it with
> the master key checksum?  Does this not effectively reduce the possible
> passwords for an AES 256 bit volume to a password of 160 bit length?

It does. If you can create that table, which you cannot. 

2^160 is about 1.5*10^48. The number of atoms in this planet
is only 1.33*10^50. So if you can convert the whole planet to 
storage space and can store one bit in one atom, you can just 
about do it. Then there is the computing effort: Say, you get 
1M hashes/sec with 1W of power. As PBKDF2 runs with around 
100'000 iterations on average PC hardware, you then get 1
iterated hashe for 0.1 Joule of power. That means for 2^160
of them, you need 150*10^45 Joules. The sun has an energy
output of 3.8*10^26 W. So run the sun for 384*10^18 seconds =
12.8*10^12 years and you have your table.

Sounds pretty unrealistig, right?

AES-256 does not have a 256 bit key to provide a 2^256-sized 
key-space. Key-space-wise, at around 100 bit it becomes reliably 
infeasible for the human race to break things.

AES-256 has a 256 bit key, becuase research could reduce the
effective key-length and the longer the key, the more effective
bits need to be removed by research before brute-forcing becomes 
feasible.

Also note that your password is unlikely to even have 100 bits
of entropy. If you actually use a passwored with more than
160 bits of entropy, moving to SHA-256 as hash function may 
provide an irrelevant security improvement.

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
----
There are two ways of constructing a software design: One way is to make it
so simple that there are obviously no deficiencies, and the other way is to
make it so complicated that there are no obvious deficiencies. The first
method is far more difficult.  --Tony Hoare

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Heinz]

Arno Wagner <arno@...> writes:

> No, that is not the statement. The statement is that collision attacks
> (the SHA1-weakness) are irrelevant for password hasing.

Or in other words, SHA1 is secure in this case. But why not always use the
best possible hash algorithm, instead of an option which is at least safe?
I would logically use always the strongest one, purely as a precaution, and
not what has already demonstrated weaknesses of any kind. I would not want
to wait if SHA1 really holds a long time. :)
 
> 2^160 is about 1.5*10^48. The number of atoms in this planet
> is only 1.33*10^50. So if you can convert the whole planet to 
> storage space and can store one bit in one atom, you can just 
> about do it. Then there is the computing effort: Say, you get 
> 1M hashes/sec with 1W of power. As PBKDF2 runs with around 
> 100'000 iterations on average PC hardware, you then get 1
> iterated hashe for 0.1 Joule of power. That means for 2^160
> of them, you need 150*10^45 Joules. The sun has an energy
> output of 3.8*10^26 W. So run the sun for 384*10^18 seconds =
> 12.8*10^12 years and you have your table.
> 
> Sounds pretty unrealistig, right?

Yes, but for me a very original presentation.

If i am not mistaken, a computing power of at least 10^42 FLOPS would be
needed to effectively go through this area.
2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.

> Also note that your password is unlikely to even have 100 bits
> of entropy. If you actually use a passwored with more than
> 160 bits of entropy, moving to SHA-256 as hash function may 
> provide an irrelevant security improvement.

All over 128 bits is really overkill.

I once extracted my masterkey and wonder, why this consists only of numbers
and the letters a-f?
Why not a-z/A-Z? And special characters?
Okay respect brute-force attacks is a key space of 16^128 in fact
impossible, but why not exploit the maximum of what is possible? :)

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Michael Kjörling]

On 22 Aug 2015 03:38 +0000, from wurzelsepp1337@web.de (Heinz):
> If i am not mistaken, a computing power of at least 10^42 FLOPS would be
> needed to effectively go through this area.
> 2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
> technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.

This holds only if a full SHA-1 hash computation can be reduced to a
single floating-point operation, which it cannot; hashing a 64-byte
block with SHA-1 takes somewhere around 40,000 integer operations,
plus any applicable memory accesses. For a back-of-the-envelope
calculation, add four orders of magnitude to your figure.

Also, it disregards the key derivation iteration, which adds another
several orders of magnitude in practice to converting a LUKS
passphrase into a keyslot key. Add another four or five orders of
magnitude to your figure.

So on this hypothetical system that can do 10^42 flops and has similar
integer performance, your 16 (1.6 × 10^1) days instead become
something more like 1.6 billion to 16 billion (1.6 × 10^9 to
1.6 × 10^10) days.

To put this in perspective, that's only two orders of magnitude less
than the time elapsed since the Big Bang (13.798 × 10^9 years or
5.04 × 10^12 days).

And 10^42 flops isn't even on the horizon as far as computational
capability is concerned. Some comparison: Wikipedia lists the fastest
single computer as of mid-2013 as having a floating-point performance
of 33.86 petaflops (3.386 × 10^16 flops). You'd need some 2.95 × 10^25
(29,500,000,000,000,000,000,000,000), or something like 10^15 for
every person on Earth, of those computers to get to 10^42 flops. Again
Wikipedia claims that supercomputers are expected to reach one exaflop
(10^18 flops) in 2018; at 10^18 flops, you'd need 10^24 (that's a
measly 1,000,000,000,000,000,000,000,000) such computers to reach
10^42 flops. One manufacturer apparently claims to be able to deliver
a 17.1 exaflop (1.71 × 10^19 flops) computer in 2020; you'd need
5.85 × 10^22 (58,500,000,000,000,000,000,000) such computers to get
10^42 flops, and we currently don't even have _one_.

That's not to say that LUKS is invulnerable, especially in practice.
It does however make it seem likely that an adversary would pick a
different attack. It would be much cheaper, and less obvious, to
install a key logger, or hire some criminals to kidnap and torture
your family until you give up the passphrase.

-- 
Michael Kjörling • https://michael.kjorling.se • michael@kjorling.se
OpenPGP B501AC6429EF4514 https://michael.kjorling.se/public-keys/pgp
                 “People who think they know everything really annoy
                 those of us who know we don’t.” (Bjarne Stroustrup)

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Arno Wagner]

On Sat, Aug 22, 2015 at 12:04:08 CEST, Michael Kjörling wrote:
[...]
> That's not to say that LUKS is invulnerable, especially in practice.
> It does however make it seem likely that an adversary would pick a
> different attack. It would be much cheaper, and less obvious, to
> install a key logger, or hire some criminals to kidnap and torture
> your family until you give up the passphrase.

Or maybe expose what websites you were subscribed on to your 
wive, or hack your computer and put some illegal stuff on it 
and threaten to tell the authorities. "Rubber hose" crypto does
not need physical presence anymore these days.

I very much agree, and so does what we observe in practice. The 
crypto can be made hard enough to be secure in the sense that
an attack on it costs far too much. I believe LUKS has that at
this time with the defaults. But the surrounding systems are an
entirely different matter and massively more complex, and even
more so when you leave the computer and include the user.

It is important to allways look at the complete situation in
applied crypto and IT security in general (which is one of the 
main things that makes it so hard) or you end up with a house
that has a 30 centimeter steel door at the front and only
a fly-net at the backdoor. 

Regards,
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] question regarding Sha1 and 512 bit key xts mode

[Heinz]

Michael Kjörling <michael@...> writes:

> 
> On 22 Aug 2015 03:38 +0000, from wurzelsepp1337 <at> web.de (Heinz):
> > If i am not mistaken, a computing power of at least 10^42 FLOPS would be
> > needed to effectively go through this area.
> > 2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
> > technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.
> 
> This holds only if a full SHA-1 hash computation can be reduced to a
> single floating-point operation, which it cannot; hashing a 64-byte
> block with SHA-1 takes somewhere around 40,000 integer operations,
> plus any applicable memory accesses. For a back-of-the-envelope
> calculation, add four orders of magnitude to your figure.
> 
> Also, it disregards the key derivation iteration, which adds another
> several orders of magnitude in practice to converting a LUKS
> passphrase into a keyslot key. Add another four or five orders of
> magnitude to your figure.
> 
> So on this hypothetical system that can do 10^42 flops and has similar
> integer performance, your 16 (1.6 × 10^1) days instead become
> something more like 1.6 billion to 16 billion (1.6 × 10^9 to
> 1.6 × 10^10) days.
> 
> To put this in perspective, that's only two orders of magnitude less
> than the time elapsed since the Big Bang (13.798 × 10^9 years or
> 5.04 × 10^12 days).

Thanks for the clarification. Had it probably imagined too easy.
And of course, the setting of iterations is very significant that was
already aware.

> And 10^42 flops isn't even on the horizon as far as computational
> capability is concerned. Some comparison: Wikipedia lists the fastest
> single computer as of mid-2013 as having a floating-point performance
> of 33.86 petaflops (3.386 × 10^16 flops). You'd need some 2.95 × 10^25
> (29,500,000,000,000,000,000,000,000), or something like 10^15 for
> every person on Earth, of those computers to get to 10^42 flops. Again
> Wikipedia claims that supercomputers are expected to reach one exaflop
> (10^18 flops) in 2018; at 10^18 flops, you'd need 10^24 (that's a
> measly 1,000,000,000,000,000,000,000,000) such computers to reach
> 10^42 flops. One manufacturer apparently claims to be able to deliver
> a 17.1 exaflop (1.71 × 10^19 flops) computer in 2020; you'd need
> 5.85 × 10^22 (58,500,000,000,000,000,000,000) such computers to get
> 10^42 flops, and we currently don't even have _one_.

I know that this computing power does not exist, why has the taken as an
example, what would be necessary.
10^42 are 1000000000000000000000000000000000000000000 FLOPS, this is very
impressive against 10^18 in 2020~.
Especially passwords of up to 95^26 complexity would fall quickly in such a
computing power, provided that the full computing power is available and
nothing like PBKDF2 stands in the way.
But certainly we are no longer experiencing a computing power of this kind,
even if it's fascinating what is basically necessary for a computing effort
to crack passwords.

> That's not to say that LUKS is invulnerable, especially in practice.
> It does however make it seem likely that an adversary would pick a
> different attack. It would be much cheaper, and less obvious, to
> install a key logger, or hire some criminals to kidnap and torture
> your family until you give up the passphrase.

Yes, however. Where it would also be particularly important in future to
hide LUKS/dm-crypt encrypted drives, similar to the Hidden Volumes in TrueCrypt.
In order generally to conceal the existence of encrypted data, which must be
first detected.
Personally, i think Truecrypt is less secure than LUKS/dm-crypt, as this
solution has a wiser architecture for me.

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Arno Wagner]

On Sat, Aug 22, 2015 at 05:38:16 CEST, Heinz wrote:
> Arno Wagner <arno@...> writes:
> 
> > No, that is not the statement. The statement is that collision attacks
> > (the SHA1-weakness) are irrelevant for password hasing.
> 
> Or in other words, SHA1 is secure in this case. But why not always use the
> best possible hash algorithm, instead of an option which is at least safe?

SHA1 is a "best possible" for this case. Seriously.

> I would logically use always the strongest one, purely as a precaution,
> and

There is no single one-dimensional "safest" measure. It always 
depends on the scenario. 

> not what has already demonstrated weaknesses of any kind. I would not want
> to wait if SHA1 really holds a long time. :)

SHA1 is very, very unlikely to ever have a weakness that makes
reversing it easy. It is too old and too well-understood for that.
And that would be the only attack that matters. Really, what you 
advocate makes no sense. It is not readily obvious that it
makes no sense, admittedly, hence my explanation.
 
> > 2^160 is about 1.5*10^48. The number of atoms in this planet
> > is only 1.33*10^50. So if you can convert the whole planet to 
> > storage space and can store one bit in one atom, you can just 
> > about do it. Then there is the computing effort: Say, you get 
> > 1M hashes/sec with 1W of power. As PBKDF2 runs with around 
> > 100'000 iterations on average PC hardware, you then get 1
> > iterated hashe for 0.1 Joule of power. That means for 2^160
> > of them, you need 150*10^45 Joules. The sun has an energy
> > output of 3.8*10^26 W. So run the sun for 384*10^18 seconds =
> > 12.8*10^12 years and you have your table.
> > 
> > Sounds pretty unrealistig, right?
> 
> Yes, but for me a very original presentation.

Thanks!

> If i am not mistaken, a computing power of at least 10^42 FLOPS would be
> needed to effectively go through this area.
> 2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
> technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.

Not to "break" it. To reverse it in one instance.
To break it, you have to compute that table.

> > Also note that your password is unlikely to even have 100 bits
> > of entropy. If you actually use a passwored with more than
> > 160 bits of entropy, moving to SHA-256 as hash function may 
> > provide an irrelevant security improvement.
> 
> All over 128 bits is really overkill.

I completely agree.
 
> I once extracted my masterkey and wonder, why this consists only 
> of numbers and the letters a-f?
> Why not a-z/A-Z? And special characters?

A mattetr of encoding. Not a question of security at all, more 
one of compatibility and convenience. 

> Okay respect brute-force attacks is a key space of 16^128 in fact
> impossible, but why not exploit the maximum of what is possible? :)

Simplicity, use of well-knonw components, prevention of 
over-engineering. All well known and valuable engineering 
practices. Also note that in order to change the hash,
code has to be changed and that comes with the risk of 
introducing bugs. "If it aint broke, don't fix it" is
another very important engineering principle.

Listen, I can understand your view. Every budding crypto-nerd
goes through it, and I certainly have. But it is something 
you eventually grow out of when you understand the larger 
picture.

Regards,
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] question regarding Sha1 and 512 bit key xts mode

[Heinz]

Arno Wagner <arno@...> writes:

> SHA1 is a "best possible" for this case. Seriously.

Okay. I always strive to understand, and i'm interested in the respective
backgrounds.

> Not to "break" it. To reverse it in one instance.
> To break it, you have to compute that table.

Okay probably not so simple.

> > Okay respect brute-force attacks is a key space of 16^128 in fact
> > impossible, but why not exploit the maximum of what is possible? :)
> 
> Simplicity, use of well-knonw components, prevention of 
> over-engineering. All well known and valuable engineering 
> practices. Also note that in order to change the hash,
> code has to be changed and that comes with the risk of 
> introducing bugs. "If it aint broke, don't fix it" is
> another very important engineering principle.
> 
> Listen, I can understand your view. Every budding crypto-nerd
> goes through it, and I certainly have. But it is something 
> you eventually grow out of when you understand the larger 
> picture.
> 
> Regards,
> Arno
> 

No problem, i understand what you wanted to tell me, and can understand that
you should definitely consider again the overall picture.

Thanks.

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Sven Eschenberg]

On Sat, August 22, 2015 05:38, Heinz wrote:
> Arno Wagner <arno@...> writes:
>
>> No, that is not the statement. The statement is that collision attacks
>> (the SHA1-weakness) are irrelevant for password hasing.
>
> Or in other words, SHA1 is secure in this case. But why not always use the
> best possible hash algorithm, instead of an option which is at least safe?
> I would logically use always the strongest one, purely as a precaution,
> and
> not what has already demonstrated weaknesses of any kind. I would not want
> to wait if SHA1 really holds a long time. :)

Sorry to intervene here. Hashing in LUKS is only used to check if a
password/passphrase is a candidate. So, even if you manage to find a
collision, the worst that can happen is, that LUKS accepts the
'collisison' as valid key and you'll get gibberish on the mapping. Your
encrypted data will be useless 'random' data and is not compromised then.

>
>> 2^160 is about 1.5*10^48. The number of atoms in this planet
>> is only 1.33*10^50. So if you can convert the whole planet to
>> storage space and can store one bit in one atom, you can just
>> about do it. Then there is the computing effort: Say, you get
>> 1M hashes/sec with 1W of power. As PBKDF2 runs with around
>> 100'000 iterations on average PC hardware, you then get 1
>> iterated hashe for 0.1 Joule of power. That means for 2^160
>> of them, you need 150*10^45 Joules. The sun has an energy
>> output of 3.8*10^26 W. So run the sun for 384*10^18 seconds =
>> 12.8*10^12 years and you have your table.
>>
>> Sounds pretty unrealistig, right?
>
> Yes, but for me a very original presentation.
>
> If i am not mistaken, a computing power of at least 10^42 FLOPS would be
> needed to effectively go through this area.
> 2^160 / 10^42 FLOPS = 1461501 Seconds = 16 Days to break SHA1, but
> technically we arrive until approximately 10^18 FLOPS or 1 exaFLOP.
>
>> Also note that your password is unlikely to even have 100 bits
>> of entropy. If you actually use a passwored with more than
>> 160 bits of entropy, moving to SHA-256 as hash function may
>> provide an irrelevant security improvement.
>
> All over 128 bits is really overkill.
>
> I once extracted my masterkey and wonder, why this consists only of
> numbers
> and the letters a-f?
> Why not a-z/A-Z? And special characters?
> Okay respect brute-force attacks is a key space of 16^128 in fact
> impossible, but why not exploit the maximum of what is possible? :)
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Arno Wagner]

On Sun, Aug 23, 2015 at 20:51:42 CEST, Sven Eschenberg wrote:
> On Sat, August 22, 2015 05:38, Heinz wrote:
> > Arno Wagner <arno@...> writes:
> >
> >> No, that is not the statement. The statement is that collision attacks
> >> (the SHA1-weakness) are irrelevant for password hasing.
> >
> > Or in other words, SHA1 is secure in this case. But why not always use the
> > best possible hash algorithm, instead of an option which is at least safe?
> > I would logically use always the strongest one, purely as a precaution,
> > and
> > not what has already demonstrated weaknesses of any kind. I would not want
> > to wait if SHA1 really holds a long time. :)
> 
> Sorry to intervene here. Hashing in LUKS is only used to check if a
> password/passphrase is a candidate. So, even if you manage to find a
> collision, the worst that can happen is, that LUKS accepts the
> 'collisison' as valid key and you'll get gibberish on the mapping. Your
> encrypted data will be useless 'random' data and is not compromised then.

I seem to remember that PBKDF2 gets the hash discussed (SHA1) as input
and also that the AF splitter uses it. Still not an issue.

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] question regarding Sha1 and 512 bit key xts mode

[Sven Eschenberg]

Maybe I got a misconception here.

But if I remember correctly:

In case of auth, a collision might get you authed, in LUKS a collission
gets you past the candidate check, but a mere collision without hitting
the correct key, results in gibberish during decryption.

If I am wrong, please correct me here...

I was not really discussing the "excact" procedure of hashing in
cryptsetup here, but maybe I slipped on something?

Regards

-Sven

P.S.: It's been a while since I read the source of cryptsetup ;-).

On Sun, August 23, 2015 21:38, Arno Wagner wrote:
> On Sun, Aug 23, 2015 at 20:51:42 CEST, Sven Eschenberg wrote:
>> On Sat, August 22, 2015 05:38, Heinz wrote:
>> > Arno Wagner <arno@...> writes:
>> >
>> >> No, that is not the statement. The statement is that collision
>> attacks
>> >> (the SHA1-weakness) are irrelevant for password hasing.
>> >
>> > Or in other words, SHA1 is secure in this case. But why not always use
>> the
>> > best possible hash algorithm, instead of an option which is at least
>> safe?
>> > I would logically use always the strongest one, purely as a
>> precaution,
>> > and
>> > not what has already demonstrated weaknesses of any kind. I would not
>> want
>> > to wait if SHA1 really holds a long time. :)
>>
>> Sorry to intervene here. Hashing in LUKS is only used to check if a
>> password/passphrase is a candidate. So, even if you manage to find a
>> collision, the worst that can happen is, that LUKS accepts the
>> 'collisison' as valid key and you'll get gibberish on the mapping. Your
>> encrypted data will be useless 'random' data and is not compromised
>> then.
>
> I seem to remember that PBKDF2 gets the hash discussed (SHA1) as input
> and also that the AF splitter uses it. Still not an issue.
>
> 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
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
>

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Milan Broz]

On 08/23/2015 10:21 PM, Sven Eschenberg wrote:
> Maybe I got a misconception here.
> 
> But if I remember correctly:
> 
> In case of auth, a collision might get you authed, in LUKS a collission
> gets you past the candidate check, but a mere collision without hitting
> the correct key, results in gibberish during decryption.

Yes. Maybe this should be added to FAQ...

Just a little bit engineering background to the theory below :)

The hash algorithms specified in LUKS header is used to:

 1) underlying PBKDF2 for derivation of keyslot unlocking password
    (keyslot is encrypted with the same algorithms as data with this derived key)

 2) Decrypted key candidate digest check.

 3) Anti-forensic (AF) LUKS splitter

 (4) the hash used for ESSIV was always SHA256 as a default, this is unrelated
  to hash mentioned above and it is already "obsoleted" by using XTS mode where
  we do not need ESSIV)

Just note, for 2) there we have only 20bytes in header for MK digest.
(IOW it was designed for SHA1.)

This is really not a real problem, because even if you find the collision,
you have wrong key and result is decrypted gibberish (as Sven already said).

And why SHA1 as a default?
Well, it is history and more about user experience trade-off that anything else.

- original LUKS implementation had SHA1 hardcoded, old implementation
cannot decrypt anything else (pre 1.1.x versions)

- in >= 1.1.x the library SHA1 is used and code allows switch to other
hash algorithm (provided by underlying crypto library).

But because in that time (~2010) most of implementations in stable distro
releases had SHA1 hardcoded, it would make LUKS incompatible.
(Moreover using SHA1 is still not a problem there, otherwise security
aspects would have priority even if it means breaking compatibility.)

Today, it is probably possible to change hash default without a big hassle.
But we have more serious problem here: PBKDF2, which is no longer the best
KDF we can use here.

So the plan is to introduce slightly modified LUKS2 header that
allows specifying another KDF (probably per-slot) and some
other things and this would be the best time to switch the hash default
as well.

(Despite SHA1 is not problematic for this use case, it will be soon banned
in some environments. And there is a compile switch to change default for years,
so distros can change it.)

There will be some experimental branch in distro for prototyping this
(heading to cryptsetup 2.x & LUKS2.

Milan

Re: [dm-crypt] question regarding Sha1 and 512 bit key xts mode

[Arno Wagner]

On Mon, Aug 24, 2015 at 08:18:39 CEST, Milan Broz wrote:
> 
> On 08/23/2015 10:21 PM, Sven Eschenberg wrote:
> > Maybe I got a misconception here.
> > 
> > But if I remember correctly:
> > 
> > In case of auth, a collision might get you authed, in LUKS a collission
> > gets you past the candidate check, but a mere collision without hitting
> > the correct key, results in gibberish during decryption.
> 
> Yes. Maybe this should be added to FAQ...

Indeed. It is a less frequently asked question, bit it does get 
asked from time to time. I will write something.
 
> Just a little bit engineering background to the theory below :)
> 
> The hash algorithms specified in LUKS header is used to:
> 
>  1) underlying PBKDF2 for derivation of keyslot unlocking password
>     (keyslot is encrypted with the same algorithms as data with this 
>     derived key)
> 
>  2) Decrypted key candidate digest check.

I think this has something like 0.25 seconds of PBKDF2 iterations 
well.
 
>  3) Anti-forensic (AF) LUKS splitter
> 
>  (4) the hash used for ESSIV was always SHA256 as a default, this is unrelated
>   to hash mentioned above and it is already "obsoleted" by using XTS mode where
>   we do not need ESSIV)
> 
> Just note, for 2) there we have only 20bytes in header for MK digest.
> (IOW it was designed for SHA1.)

Which is actually an advantage, as the MK may have 256 bits of
entropy, this has only has 160. That means even if you can reverse
the MK iterations of PBKDF2, you are still short 96 bits. This
should probably be kept or even shortened to 128 bits in the
next LUKS header version.

> This is really not a real problem, because even if you find the collision,
> you have wrong key and result is decrypted gibberish (as Sven already said).

You could trick things that check for a vcalid key but
never decrypt anything. That would be a pretty gross misuse
of LUKS, so we do not need to care aboyt it.
 
> And why SHA1 as a default?
> Well, it is history and more about user experience trade-off that anything
> else.
> 
> - original LUKS implementation had SHA1 hardcoded, old implementation
> cannot decrypt anything else (pre 1.1.x versions)
> 
> - in >= 1.1.x the library SHA1 is used and code allows switch to other
> hash algorithm (provided by underlying crypto library).
> 
> But because in that time (~2010) most of implementations in stable distro
> releases had SHA1 hardcoded, it would make LUKS incompatible.
> (Moreover using SHA1 is still not a problem there, otherwise security
> aspects would have priority even if it means breaking compatibility.)
> 
> Today, it is probably possible to change hash default without a big hassle.
> But we have more serious problem here: PBKDF2, which is no longer the best
> KDF we can use here.

While the winner of the password hashing competition is known,
they ares till finalizing it, as far as I remember. This thing
is much more advanced than PBKDF2.

> So the plan is to introduce slightly modified LUKS2 header that
> allows specifying another KDF (probably per-slot) and some
> other things and this would be the best time to switch the hash default
> as well.

Indeed.
 
> (Despite SHA1 is not problematic for this use case, it will be soon banned
> in some environments.  And there is a compile switch to change default for
> years, so distros can change it.)

I think that is the main reason for eventually changing it/making it
configurable: Users that cannot use SHA1 for any purpose due an
organizational ban. This should also get an FAQ item along the
lines "Help, I am forbidden to use SHA1!".

> There will be some experimental branch in distro for prototyping this
> (heading to cryptsetup 2.x & LUKS2.

Ecellent. If you want feedback on the new header format and things,
please let me know. As the original design of the header wisely
includes a version number, compatibility should not be an issue
though. 

Regards,
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