Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98272
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXb2VHO6hxNut3mLSmEOn1iTmVZAJ-vE2XxTafPLASJ8Cw@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> <CAGa2bXb2VHO6hxNut3mLSmEOn1iTmVZAJ-vE2XxTafPLASJ8Cw@mail.gmail.com>
Date: Thu, 9 Feb 2017 08:52:27 -0500
Message-ID: <CAKws9z1iOXvvvLAc79JmYNgkuhu-=0QKs46DUZS7p7h9y8fx5Q@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113ce83cb1c8700548194a3d
Subject: Re: [PHP-DEV] hash_hkdf() signature
From: scott@paragonie.com (Scott Arciszewski)

--001a113ce83cb1c8700548194a3d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 9, 2017 at 7:51 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> 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/rf
>> c5869.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 typica=
l
> "length" use with PHP?
>
> HKDF relies on PRK being cryptographically strong.
>
> Extract step
>    PRK =3D 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 cryptograph=
y
>> 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! <=3D Must not do this.
> ----------------
>
> ----------------
> What's the reason why you trying to disregard RFC 5869 strongly recommend=
s?
> ----------------
>
> ----------------
> 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
>

=E2=80=8BHi,

=E2=80=8B
> =E2=80=8BHKDF relies on PRK being cryptographically strong.
> =E2=80=8B
> =E2=80=8B



=E2=80=8BYes, b=E2=80=8But not for the reasons you might suspect.

=E2=80=8BThe main use case of HKDF is to completely prevent related-key att=
acks,
while splitting a single key into several for domain-specific purposes.=E2=
=80=8B
Figuring out a subkey (by sheer luck) should also not give an attacker
enough information to recreate the IKM.

HKDF isn't meant for key stretching (e.g. use an 80-bit secret in an
application that requires a 256-bit secret). That's what a password hashing
function is for. (Bcrypt, Argon2, etc.)

=E2=80=8B
> =E2=80=8BYou should understand users _must_ make sure either "salt" or "I=
KM" is

strong for HKDF to work. Since hash_hkdf() is generic function, you never

can make sure IKM to be strong always.=E2=80=8B

=E2=80=8B=E2=80=8B

Not quite. IKM has to be strong. The salt? Not so much.

In cryptography protocols, salts are considered public information (even if
you don't go out of your way to publish it).

If you have a weak IKM but a strong salt (32 bytes from random_bytes()),
you should still consider the OKM weak.
=E2=80=8B

> 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.



Don't get me wrong: Having secure random salts is useful (serves as a
useful way to enlarge the effective nonce in a symmetric encryption
protocol).

But the cryptographic secret in this protocol is IKM. Not the salt.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>=E2=80=8B

--001a113ce83cb1c8700548194a3d--