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

[Milan Broz <gmazyland@gmail.com>]

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