Hi Niklas, On Fri, Sep 8, 2017 at 7:27 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> 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. > I was thinking in password hashing context, not key derivation. I was wrong. (as well as you) I take it back last statement. Even with super weak passwords, attackers cannot guess the derived keys when "Salt" is used properly. i.e. Strong random "secret" salt makes derived key a perfect random. Although, there is minor issues (i.e. misuse), users can safely use HKDF with any passwords. Now, please discuss the most important. Are we going to fix the hash_hkdf() API mess or not? Regards, -- Yasuo Ohgaki
