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  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]
Date: Sun, 9 Mar 2014 22:05:42 +0100
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] KDF vs PHS?


PHS = Password Hashing Scheme, the term used on It's not perfect but it's the
best we found then. KDF is obviously worse, as key derivation (that
is, producing a cryptographic key from a password) is only one of the
applications of password hashing.

On Sun, Mar 9, 2014 at 10:08 AM, Bill Cox <> wrote:
> Should we be calling our password hashing entries PHSs or KDFs?  I'm
> not sure people know what to call these things, and that makes it
> difficult to even discuss them.
> I see the acronym PHS on the password site twice, with no
> definition, and Google doesn't seem to know it.  Is it Password
> Hashing System?  If so, I like it better than KDF, and would propose
> we start calling them that.  I see Scrypt calls itself a KDF, while
> Catena calls itself a Password Hashing Framework, which seems
> completely different, even though they are very similar and both very
> different than PBKDF2 or HKDF.  In fact Scrypt calls PBKDF2 as a
> lower-level primitive.  How can it also be a KDF?
> KDF has the word Function in it, implying rather simple functionality,
> and when I look at standards (or just "Informational" publications)
> like PBKDF1, PBKDF2, and HKDF, I see definitions like this:
> PRK = HMAC-Hash(salt, IKM)
> These KDFs seem to be very basic cryptographic primitives, where we
> can write them if a few lines of code and then debate them for years.
> I don't see how they can be compared to Scrypt, accept from a user
> point of view where he has to select one in a drop-down menu, and we
> would like him to see Script right along PBKDF2-SHA256 and Bcrypt.
> I wrote an upgraded version of HKDF yesterday.  I abused the name HKDF
> yesterday and and called my function HKDF2 because I was too lazy to
> come up with a new name, and HKDF2 does get across my intention that
> it be an upgraded version of HKDF, rather than something completely
> new.  HKDF2 unfortunately implies the authors came out with a new
> version, so I think I'll have to come up with something else.
> "Enhanced HKDF" or EHKDF?
> That feels like a the right sort of label.  It took a day to think
> about what functionality was needed, and a couple hours to code.  I
> could be write the document tomorrow and be done, other than the
> enormous effort at standardization which frankly I'm too lazy to
> attempt.  I feel comfortable comparing it to other KDFs like PBKDF2.
> However, I would not compare it to Scrypt.  It's something that a
> password hashing system like Scrypt would call.
> In fact, I'm hoping we can have a discussion about all calling the
> same (or similar) KDF primitive as a pre-process to our password
> hashing systems.
> There... that felt good.  With different labels, I can discuss them in
> the same sentence while making sense!  What would people think if I
> propose that we all adopt a common KDF and call it as a pre-process to
> our KDFs, and that we be allowed to "tweak" our KDFs to use a
> different KDF during the KDF tweaking period of the KDF competition?
> Because that's exactly what I'm proposing, and I'd like to be able to
> say it and be understood at the same time.
> Bill

Powered by blists - more mailing lists