Hi Niklas, On Fri, Sep 8, 2017 at 6:38 PM, Niklas Keller <m...@kelunik.com> wrote:
> I finally find out what's wrong. >> > > No, you didn't. You still want to use user-supplied passwords as IKM. HKDF > is not suited for that purpose. > Andrey and Nikita clearly misunderstood the RFC 5869. This is what was wrong in previous discussions. Weak key usage is smaller issue as I insisted HKDF is perfectly good for CSRF token, API keys and URI signing. These 3 would be the most common PHP HKDF applications. What do you mean by "No, you didn't"? I totally agree with that weak key has more risks. The risk is too obvious for any algorithms. Suppose we have "A" as the key, there is no protection at all. Not even PBKDF2 or anything can protect such passwords. I think you don't mean users shouldn't use key derivation with password. Users may use HKDF and password with the security level of the password. RFC 5689 - https://tools.ietf.org/html/rfc5869#section-3.3 >> -------- >> In some applications, the input key material IKM may already be >> present as a cryptographically strong key. In this case, one can skip the >> extract part and use IKM directly to key HMAC in the expand step. >> --------- >> >> Therefore, you are debating "IKM should be strong always" and >> "salt is pure optional parameter". >> > > Yes, HKDF might be used for lower-entropy IKM, but not for short inputs > like passwords. The extract part requires a large low-entropy input to > concentrate the entropy into a smaller output. HKDF doesn't add / amplify > entropy, but it can concentrate a larger low-entropy input to a > smaller output with entropy. > > Further reading material: https://eprint.iacr.org/2010/264.pdf > Thank you nice reading. I've read briefly. It sounded like SHA-2 and SHA-3 difference that could be ignored in practice now. Now issue is whether we'll fix the improper and inconsistent API or not. Thank you Niklas, -- Yasuo Ohgaki yohg...@ohgaki.net
