Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100463
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: <CAGa2bXZTCcZKdnz=zAwa=S7-Sur=H4O0OXLAAN8_aRzB33a7Tg@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>
Date: Fri, 8 Sep 2017 17:57:53 +0900
Message-ID: <CAGa2bXb-5UO4jZRf1rjdQ97BjCa9uUefpXRd3Bc-jw-kdw5-5g@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="f403045fb1c820f1860558a9c8af"
Subject: Re: [PHP-DEV] Re: hash_hkdf() signature and return value
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--f403045fb1c820f1860558a9c8af
Content-Type: text/plain; charset="UTF-8"

Hi all,

I finally find out what's wrong.

Andrey and Nikita, you missed

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".

The section 3.3 is clearly expecting and allowing "weak keys", isn't it?
Existence of "salt" parameter is the evidence.

No wonder why you couldn't present reasonable example codes w/o salt.
Salt should/must be used for both strong and weak keys for better and
mandatory security.

Regards,

P.S. Thank you Niklas! Now we will have conclusion.


--
Yasuo Ohgaki
yohgaki@ohgaki.net

On Fri, Sep 8, 2017 at 5:44 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi Niklas,
>
> On Fri, Sep 8, 2017 at 4:57 PM, Niklas Keller <me@kelunik.com> wrote:
>
>> Note for others:  "The extract step in HKDF can concentrate existing
>>> entropy
>>>  but cannot amplify entropy." is not came from the RFC. If a RFC states
>>> this I would be stunned. Please read on you'll see the evidence.
>>>
>>
>> This is ridiculous. Be stunned. It's right in the section about
>> applications of HKDF: https://tools.ietf.org/html/rfc5869#section-4, in
>> the middle of the second paragraph.
>>
>> Please stop, it's enough.
>>
>
> This is my bad I didn't understand "amplify" well.
> I mixed up "add" and "amplify" I admit this.
> However, the reason why I mixed up is Andrey's misunderstanding about
> HMAC nature.
>
> Andrey's words.
> ------
>    The extract step in HKDF can concentrate existing entropy but
> cannot amplify entropy.
>
> Which means that it is NOT designed to do key stretching, or in other
> words it should NOT be relied upon to produce strong outputs from weak
> inputs - the exact scenario for which you wanted to make salts
> non-optional.
> -------
>
> Following is wrong by HMAC nature.
> -------
> it should NOT be relied upon to produce strong outputs from weak
> inputs
> -------
>
> Who would think resulting $hash of following is insecure?
> $hash = hash_hmac('sha256', $weak_msg, $strong_key);
>
>
>
> RFC-5689 - https://tools.ietf.org/html/rfc5869#section-4
> ---------
> One significant example is the derivation of cryptographic
> eys from a source of low entropy, such as a user's password.  The
> extract step in HKDF can concentrate existing entropy but cannot
> amplify entropy.  In the case of password-based KDFs, a main goal is
> to slow down dictionary attacks using two ingredients: a salt value,
> and the intentional slowing of the key derivation computation.  HKDF
> naturally accommodates the use of salt; however, a slowing down
> mechanism is not part of this specification.  Applications interested
> in a password-based KDF should consider whether, for example, [PKCS5]
> meets their needs better than HKDF.
> ---------
>
> This whole sentence means HKDF cannot be used like PBKDF2. That's all.
> This is does not support Andrey's statement
> -------
> it should NOT be relied upon to produce strong outputs from weak
> inputs
> -------
>
> Instead, he should read this section.
>
> 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.
> ---------
>
> "one can skip the extract part" is "one can omit salt".
>
> Obviously, the RFC is prepared for weak keys and it is perfectly OK to
> use weak keys unlike Andrey statement.
>
> If IKM should be strong always, HKDF would NOT have salt at all.
> However, HKDF has salt.
> Weak IKM is explicitly allowed by HKDF definition.
>
> Andrey, sorry for my confusion, but your claim is wrong by HKDF
> (HMAC) definition still.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohgaki@ohgaki.net
>
>
>

--f403045fb1c820f1860558a9c8af--