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

Arno Wagner arno at wagner.name
Mon Aug 24 13:54:18 CEST 2015


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


More information about the dm-crypt mailing list