Newsgroups: php.doc,php.internals
Path: news.php.net
Xref: news.php.net php.doc:969386568 php.internals:98874
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.218.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbr2nxQkdvkcfNf7CPzV1H6yAHYGsbxEvH9-bu+v21NUg@mail.gmail.com>
References: <CAGa2bXbUYDgJxmmZfuS5ZbWCLjq0QPpDioM-zkU9j7EHA-D_ag@mail.gmail.com>
 <CAGa2bXYFw6Uz9cLFM1QT9ULak9uJcM4mr0R59TEa0eYf-tAm+Q@mail.gmail.com>
 <CAGa2bXYnDgvsWi4kCdajnnQ-psCPThpLu3_EK_DprLWsX+UZ2A@mail.gmail.com>
 <CAL=_i_n4KSfx=TGMjTnjjszaNzVqT=V=GPZFyiLYFuzb8RxCgQ@mail.gmail.com>
 <CAGa2bXZ6JMKWsY=Cea-=V=g09jdTQGDOg7TtJrf6_higU0KW3Q@mail.gmail.com>
 <1924612862.1298112.1492071094545.JavaMail.zimbra@pieterhordijk.com>
 <CAGa2bXYR5ssff9YXUYGcsriTWJfYEf-2OkTXAxnb536HPhBjpA@mail.gmail.com>
 <CAF+90c81-1gA9-3UfwN6ohcu587He22wN9ekMiDsbNkyYmmZmw@mail.gmail.com>
 <690015854.1384408.1492163148986.JavaMail.zimbra@pieterhordijk.com>
 <CAGa2bXY2kwasyH4GwoSfSr6XcMcg1jukcMXOEUPvBg8pLCbDkg@mail.gmail.com>
 <CAGa2bXa+wfcVbeX32t8kOiL7Bz1dBnvwweSwoLETpEiw=rTyoA@mail.gmail.com>
 <CANUQDCgHLQVzY08CtS_QA6vsao+hpejKGAuyB1eETEcEmpcxhg@mail.gmail.com>
 <CAGa2bXaNECDwA8vwqZwvzM=pZYciLPbX9dOr62duZpg43CzSrg@mail.gmail.com>
 <CAPhkiZzXjfEZ_gDnCXd-ivoDQJ5rp3vuOb5yfjzX_7nnca6nEw@mail.gmail.com> <CAGa2bXbr2nxQkdvkcfNf7CPzV1H6yAHYGsbxEvH9-bu+v21NUg@mail.gmail.com>
Date: Tue, 25 Apr 2017 13:17:14 +0300
Message-ID: <CAPhkiZyen34Y6TV78m8bMLdRFyQu2+Q_Opa=0xcA=dSmya8xsQ@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: Niklas Keller <me@kelunik.com>, Pieter Hordijk <info@pieterhordijk.com>, 
	Joe Watkins <pthreads@pthreads.org>, internals <internals@lists.php.net>, 
	phpdoc <phpdoc@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
From: narf@devilix.net (Andrey Andreev)

Hi,

On Tue, Apr 25, 2017 at 3:28 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>>
>> If you want examples, search GitHub for PHP code utilizing HKDF - you
>> will see that most projects use it without a salt, including
>> https://github.com/defuse/php-encryption - pretty much the best PHP
>> userspace crypto library today. And I'm only saying "most" because I
>> can't be bothered to go through literally all of them; I've found NONE
>> that do use the salt.
>
>
> Wrong.
> I don't think the author wouldn't make such mistake, so I checked.
>
>     /**
>      * Derives authentication and encryption keys from the secret, using a
> slow
>      * key derivation function if the secret is a password.
>      *
>      * @param string $salt
>      *
>      * @throws Ex\EnvironmentIsBrokenException
>      *
>      * @return DerivedKeys
>      */
>     public function deriveKeys($salt)
>     {
>         if (Core::ourStrlen($salt) !== Core::SALT_BYTE_SIZE) {
>             throw new Ex\EnvironmentIsBrokenException('Bad salt.');
>         }
>
>         if ($this->secret_type === self::SECRET_TYPE_KEY) {
>             $akey = Core::HKDF(
>                 Core::HASH_FUNCTION_NAME,
>                 $this->secret->getRawBytes(),
>                 Core::KEY_BYTE_SIZE,
>                 Core::AUTHENTICATION_INFO_STRING,
>                 $salt
>             );
>             $ekey = Core::HKDF(
>                 Core::HASH_FUNCTION_NAME,
>                 $this->secret->getRawBytes(),
>                 Core::KEY_BYTE_SIZE,
>                 Core::ENCRYPTION_INFO_STRING,
>                 $salt
>             );
>             return new DerivedKeys($akey, $ekey);
>         } elseif ($this->secret_type === self::SECRET_TYPE_PASSWORD) {
>
>

Fair enough, it uses a salt somewhere I didn't see - as I said, I
didn't check literally everything.
It doesn't use it here:
https://github.com/defuse/php-encryption/blob/0364e3ea20d2382e709034e972d474f551c3273c/src/Crypto.php#L124

>>
>> You will also find zero projects using it for CSRF protection.
>
>
> You obviously does not understand HKDF RFC at all. (And don't read my reply)
> It seems you consider HKDF as a specific KDF, but it is _not_.
>

I'm telling you nobody uses it for CSRF and you can't disprove that,
but somehow that means I don't understand RFC 5869?!

> HKDF is designed as general purpose KDF. It is clearly stated in RFC 5869
>
> 4.  Applications of HKDF
>
>    HKDF is intended for use in a wide variety of KDF applications.
>
>
> Just because you cannot think of how general purpose KDF could be used
> for other purposes, it does not mean it should not be used other purposes.
> Especially when it is designed for general purpose in the first place.
>

First of all, KDF is a *cryptographic* term.
The fact that you don't know this should disqualify you of even being
involved in this discussion, and it is laughable that you're trying to
tell anybody that they don't understand RFC5869.

Secondly, you're cherry-picking a single sentence, out of context and
twisting its meaning to serve your personal agenda.
Here's the entire paragraph in question:

   HKDF is intended for use in a wide variety of KDF applications.
   These include the building of pseudorandom generators from imperfect
   sources of randomness (such as a physical random number generator
   (RNG)); the generation of pseudorandomness out of weak sources of
   randomness, such as entropy collected from system events, user's
   keystrokes, etc.; the derivation of cryptographic keys from a shared
   Diffie-Hellman value in a key-agreement protocol; derivation of
   symmetric keys from a hybrid public-key encryption scheme; key
   derivation for key-wrapping mechanisms; and more.  All of these
   applications can benefit from the simplicity and multi-purpose nature
   of HKDF, as well as from its analytical foundation.

Link: https://tools.ietf.org/html/rfc5869#section-4

And finally, but what is most important as far as PHP documentation goes:

 - Can HKDF be somehow used for CSRF protection? Sure, a lot of things
*happen* to be usable for different things they weren't intended for.
 - Should HKDF be used for CSRF protection? Maybe, if you want an
overkill solution - a simple HMAC is more than sufficient if you want
to couple your CSRF tokens with the server state.
 - Is CSRF token generation what HKDF was made for? Absolutely NOT,
and you know it.

It's none of our business to *invent* new use cases and document them
as if that's what everybody should do.
For all I care, use it however you wish in your own code, but the PHP
documentation is not your personal blog.

>> The vote ended with 1 Yes (you) and 14 No; not a single person has
>> agreed with you so far, and most have explicitly stated strong
>> disagreement with your proposed changes. Yet you insist on pushing
>> your *personal opinion*, ignoring everybody else and acting as if ~80
>> mails haven't already been exchanged.
>>
>>
>> How is it even possible that you still believe that everybody is wrong
>> and you alone are right? Give it up already.
>
>
> Prove my idea in the manual (or my RFC) is wrong by logic, rather than FUD.
>

I just did, but since you insist - there's more.

Your RFC lists multiple examples of using *user-provided plain-text
passwords* for IKM, and you describe those as valid use cases.

Well, I was prepared to compare HKDF to PBKDF2, as the latter also
uses HMACs and a salt, but I don't even have to do that.
Because guess what Section 4 of RFC 5869 says about passwords? The
very same "Applications of HKDF" section that you cherry-pick from:

   On the other hand, it is anticipated that some applications will not
   be able to use HKDF "as-is" due to specific operational requirements,
   or will be able to use it but without the full benefits of the
   scheme.  One significant example is the derivation of cryptographic
   keys 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.

Link: https://tools.ietf.org/html/rfc5869#section-4

And this doesn't stop at passwords. Please note that this paragraph
explicitly states this:

   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.

---------------------

Is this FUD? Do we all still not understand HKDF, while you're the
only person on the planet who does?

And will you at least stop with the "I will commit unless somebody
comments" emails?
When everybody is unanimously against your changes, that means don't do them.

Cheers,
Andrey.