Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CANUQDCiTCX18dg4zGcff_YuryOdyWCwbpC8jByavxv3-xnEUbw@mail.gmail.com>
References: <CAGa2bXbDNe-ruMrkv=gTcq8x_jfuQCjOhzzTRsKy4VdVkOyaWQ@mail.gmail.com>
 <CAGa2bXZdRG+WxQwY3Be7Jg1WChikrbfk76ZSkG2xS=fyxHG=kA@mail.gmail.com>
 <CAPhkiZy+z+JLm-b3rNm-ASiLPBey4kr7kO-D6fOp0ur7K2GNgA@mail.gmail.com>
 <CAGa2bXa8aGZeLd31fAHVwSu6jX=7=7PjfP1-kY3NX+1X-12uJQ@mail.gmail.com>
 <CANUQDCh-gmEVMM4h=fDF1DyS3t-u2B=Gs1TG6deAR8f27AsCkQ@mail.gmail.com>
 <CAGa2bXZTCcZKdnz=zAwa=S7-Sur=H4O0OXLAAN8_aRzB33a7Tg@mail.gmail.com>
 <CAGa2bXb-5UO4jZRf1rjdQ97BjCa9uUefpXRd3Bc-jw-kdw5-5g@mail.gmail.com> <CANUQDCiTCX18dg4zGcff_YuryOdyWCwbpC8jByavxv3-xnEUbw@mail.gmail.com>
Date: Fri, 8 Sep 2017 19:27:10 +0900
Message-ID: <CAGa2bXYy-cBtnRR0Y6v2=KX6K0Dgy2FE3tCWWfeg7-S2y61_7A@mail.gmail.com>
To: Niklas Keller <me@kelunik.com>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary="001a114ab5d47694c70558ab079d"
Subject: Re: [PHP-DEV] Re: hash_hkdf() signature and return value
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114ab5d47694c70558ab079d
Content-Type: text/plain; charset="UTF-8"

Hi Niklas,

On Fri, Sep 8, 2017 at 6:38 PM, Niklas Keller <me@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
yohgaki@ohgaki.net

--001a114ab5d47694c70558ab079d--