Hi Andrey, On Sun, Feb 5, 2017 at 6:19 AM, Andrey Andreev <n...@devilix.net> wrote:
> On Sat, Feb 4, 2017 at 10:27 PM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote: > >> Hi Andrey, >> >> On Sun, Feb 5, 2017 at 3:21 AM, Andrey Andreev <n...@devilix.net> wrote: >> >>> Have *you* read anything else in the RFC? >>> >>> The reason why its authors have to recommend salt usage is because it is >>> *otherwise the only optional part of the algorithm*. >>> >> >> Nonsense. You misread the RFC and my mail. >> Who stores plain text password in db now a days? >> It should be crypt() or hash_password(). >> >> The RFC obviously recommends salt for improved security. >> It's even clear from your misunderstood usage, plain text password ikm. >> >> > Speaking of nonsense, I need you to point out where have I ever suggested > using passwords - hashed or not - as IKM. > > At this point it's not even about misunderstandings. You are literally > making things up. > Excuse me again. Have you ever read the internet RFC? Nikita also explained what's the HKDF good for in other thread. I wouldn't repeat already explained background. Please read the internet RFC. The internet RFC emphasizes on improved security by whatever "salt" values are. Your wrong usage example with plain passwords even make the value of "salt" clearer. Therefore, this signature does not make sense at all to me. string hash_hkdf(string algo, string ikm [, int length = 0 [, string info = '' [, string salt = '']]]) but string hash_hkdf(string algo, string ikm, string salt [, string info = '' [, int length = 0]]) - Set salt to NULL if salt cannot be used, reject null string as invalid. IMO, length parameter can even removed. It could be large enough buffer size or optimal buffer size could be computed in the function, if it matters. Anyway, why you insist and recommend vulnerable usage so much? You missed the most important answer. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
