phc-discussions - Re: [PHC] Are password trailing 0's a problem?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <0fd6ae38ec30f99b0b41c5e7043b630d.squirrel@www.bolet.org>
Date: Fri, 7 Mar 2014 21:58:04 -0000
From: pornin@...et.org
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Are password trailing 0's a problem?

> It seems really frightening to be rolling-my-own when HKDF
> seems to have become a standard in 2010

Hey, let's not be hasty. HKDF was first published in 2010, and the article
(which can be seen on http://eprint.iacr.org/2010/264.pdf ) contains this
sentence, right in the abstract:

   The HMAC-based scheme presented here, named HKDF, is being standardized
by the IETF.

And a footnote on page 3 further qualifies that assertion as:

   The proposed HKDF scheme is being standardized by the IETF as RFC 5869.

Ok, so let's have a look at RFC 5869: http://tools.ietf.org/html/rfc5869
And there we see that the RFC has category "INFORMATIONAL", and not at all
"STANDARDS TRACK" or "PROPOSED STANDARD".

Bottom-line: HKDF is not a standard in the IETF sense (so the assertion in
the article is a bit misleading). Being published as a RFC is in no way an
official blessing, asserting quality, or implying that you can get jailed
for not using it. An "informational" RFC only means that the author could
write in a coherent enough English some description of a technical element
that was not immediately detected as flawed (I should know -- I myself
wrote an informational RFC).

Now don't get me wrong; HDKF is a fine piece of work, and the
cryptographic arguments for its security are very good. Using it where you
need a KDF looks like a good idea. However, it is in no way a "standard"
in the same way as, say, PKCS#1 for RSA. PKCS#1 is indeed a good example,
because it is also an "informational" RFC (RFC 3447), so it is not an
"IETF standard" per se; but it is a "standard" by being de facto used
everywhere, in particular by some actual "IETF standards" (e.g. RFC 3279
and 5756). In that sense, RSA, as described in PKCS#1, has been hallowed
by the IETF. HKDF has not.

In my view, HKDF still lacks, necessarily, the very important property of
having stood the test of time. Regardless of how much mathematics we throw
at it, we still do not have a way to absolutely prove the security of any
cryptographic primitive. We have reductions, and arguments, and partial
proofs; but, ultimately, a cryptographic algorithm can be deemed "secure"
only when it has sustained the collective scrutiny of many cryptographers
for sufficiently long (years), and survived unscathed. That's actually the
point of competitions like SHA-3 or PHC, and why they unravel over so long
a time: so that candidates get that kind of heavy scrutiny. HKDF is still
a bit too new for me. I recommend that we let it stew for a few more years
(my own rule of thumb is "five years", but modulated by the amount of
interest generated in the design -- e.g. SHA-3 or AES got a lot during
their respective competitions).

Of course, using HDKF in a design which will be part of an open
competition like PHC will go a long way towards accumulating scrutiny of
HKDF, i.e. ascertaining whether it is actually secure (or not).

        --Thomas Pornin