Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:100458
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.128.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXZdRG+WxQwY3Be7Jg1WChikrbfk76ZSkG2xS=fyxHG=kA@mail.gmail.com>
References: <CAGa2bXbDNe-ruMrkv=gTcq8x_jfuQCjOhzzTRsKy4VdVkOyaWQ@mail.gmail.com>
 <CAGa2bXZdRG+WxQwY3Be7Jg1WChikrbfk76ZSkG2xS=fyxHG=kA@mail.gmail.com>
Date: Fri, 8 Sep 2017 02:14:51 +0300
Message-ID: <CAPhkiZy+z+JLm-b3rNm-ASiLPBey4kr7kO-D6fOp0ur7K2GNgA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Re: hash_hkdf() signature and return value
From: narf@devilix.net (Andrey Andreev)

Hi,

On Fri, Sep 8, 2017 at 12:32 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>
> The reason why latter is a lot more secure is related to Andrey's
> misunderstanding.
> He said "when ikm is cryptographically strong, salt wouldn't add no more
> entropy.
> so salt does not matter". (not exact sentence)
> What he said partially true, but wrong in a sense of key security.
>

I have never said that. You are aware enough of your own English
fluency, and should know not to perephrase other people's words, as
you are completely twisting their meaning.

>
> Other misunderstanding should be noted is what HKDF for. It's for general
> purpose KDF as the RFC described in HKDF application section. Andrey said
> "I'm cherry picking sentence", but the section should be what the HKDF for.
> The section even describes obscure usage, HKDF for CSPRNG. This usage
> is not even key derivation.
>

You ARE cherry-picking, and ignoring all evidence that contradicts you:

> This one I'm not sure misunderstanding or not, but probably it is.
> HKDF is designed for any ikm and works with appropriate usage. Very
> weak ikm like user entered password can be handled relatively safely.
>
> $safe_key = hash_hkdf("sha256", 'mypassword', 0, '',
> $csprng_generated_random_key);
> // $csprng_generated_random_key should be kept secret because ikm is too
> weak
>
> Without salt, it's disaster. Please note that salt is the last optional
> parameter currently.
>
> $dangerous_key = hash_hkdf("sha256", 'mypassword'); // Disaster!
>
> With this usage, attackers can build pre hashed dictionary. Even when they
> don't have
> dictionary, usual brute force attack is very effective. One may think
> additional hashing
> would mitigate risk. i.e.
>
> $dangerous_key = hash_hkdf("sha256", hash("sha256", 'mypassword')); //
> Disaster!
>
> This does not help much when algorithm is known to attackers. Brute force
> attack is
> effective still. Adding secret salt(key) helps with this usage also.
>

IKM must always be strong; this is explicitly stated in the RFC, as I
already pointed out here: https://externals.io/message/98639#98874
And the reasons why were already explained in very simple terms here:
https://externals.io/message/98250#98272

Enough already.

Cheers,
Andrey.