Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98271
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: <CAPhkiZyeYiZ4r5Rt679Q7VOeNFYteAQRR9U7D_Oo=O7Xwv4oGw@mail.gmail.com>
References: <CAGa2bXZWKqJpvWma1zdY8j+yFg-pMXBZZHpUHb=KhJQucCf+9Q@mail.gmail.com>
 <CAKws9z31kvAs16kU1QBfdTP+G0d21PYcRaCw2-8rdsZpsRxkFg@mail.gmail.com>
 <CAPhkiZzO_B5OZExTYGpwk1oBEb=J4Mvw3DYJznU3+etwSuxqsw@mail.gmail.com>
 <CAKws9z3oOuPjLutsYNfOVToMMZTfKK_o5FEpVLr6PNKyQ3YXBg@mail.gmail.com>
 <CAGa2bXa-cxxOqB__E17QTA4czp-PsaqT5DaWBm=F_+=x=QLzCw@mail.gmail.com> <CAPhkiZyeYiZ4r5Rt679Q7VOeNFYteAQRR9U7D_Oo=O7Xwv4oGw@mail.gmail.com>
Date: Thu, 9 Feb 2017 21:51:43 +0900
Message-ID: <CAGa2bXb2VHO6hxNut3mLSmEOn1iTmVZAJ-vE2XxTafPLASJ8Cw@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Scott Arciszewski <scott@paragonie.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1148a27ada945305481873bd
Subject: Re: [PHP-DEV] hash_hkdf() signature
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1148a27ada945305481873bd
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

How the manual page would be. Would it be

  "Even though 'slat' is the last optional parameter that users may omit
easily
    by mistake, users _must_ set strong salt for weak $ikm. This is
mandatory
    requirement for HKDF to work. In addition, it is advices to set salt
whenever
    possible as RFC 5689 recommends"

It can't make sense for new function.

On Thu, Feb 9, 2017 at 7:59 PM, Andrey Andreev <narf@devilix.net> wrote:

>
> The fact that you continue to talk about passwords and other low-entropy
> data as IKM shows, yet again, that you don't understand HKDF.
> It is simply not a password-based KDF; if you want that - use PBKDF2.
> Please read Section 4* of the spec: https://tools.ietf.org/html/
> rfc5869.html#section-4
>

PHP would not be a language that builds low level crypto library/feature.
I'm not sure what you mean by this. What sentences you refer as I don't
understand?

I assumed you would like to derive human typable password because
you prefer to have the most priority for "length". Do you have any typical
"length" use with PHP?

HKDF relies on PRK being cryptographically strong.

Extract step
   PRK = HMAC-Hash(salt, IKM)

You should understand users _must_ make sure either "salt" or "IKM" is
strong for HKDF to work. Since hash_hkdf() is generic function, you never
can make sure IKM to be strong always.

With this fact alone, salt must have the most priority.


> In fact, at one point I suggested the function be named just 'hkdf()' as a
> way of discouraging such misuse, because a lot of people associate the word
> "hash" with password handling.
>

> And this ...
>
>
>> I suppose most developers will use 'length' for shorter length.
>> i.e. Weaker output keys. If it's not too short, shorter key length works.
>>
>>
> Shows that you shouldn't be trusted with anything related to cryptography
> either.
> I may be no cryptographer myself, but one thing I know for sure is that
> shorter than required key lengths are *never* ok, and most encryption
> algorithms have a *fixed* key length.
>

Are you assuming converting crypto keys to be other length would be
the typical HKDF usage with PHP?
Then, I have to say your assumption is wrong.

It would be most used for CSRF key generation, object access
control, e.g. AWS S3 presigned URL, or anything related to web
app, not low level crypto.

Discussion so far would not justify use of vulnerable, i.e. PRK could
be weak very easily, signature.

And you don't answer questions to you:

----------------
Why you recommends following usage?
hash_hkdf('sha256', $weak_ikm, 9); // We can generate strong key easily,
Nice! <= Must not do this.
----------------

----------------
What's the reason why you trying to disregard RFC 5869 strongly recommends?
----------------

----------------
Parameter order must reflect
 - importance of the parameter
 - likelihood to be used

Salt is the most important for both input and output key security.
Salt is mandatory and/or can be used for almost always with PHP.
Salt usage results in better design/security.
Salt is often used as final key as combined key.

Does 'length' and/or 'info' achieve or designed for aboves? I don't think
so.
----------------

----------------
BTW, I don't think of typical PHP application that requires
human typable short password with HKDF. What kind of
application would be?
----------------



Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1148a27ada945305481873bd--