Hi Andrey,



> Hi,
>
>
> >>
> >> 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
>
>
It is in
public static function legacyDecrypt($ciphertext, $key)
which is legacy(old and not recommended) way.


> >>
> >> 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.
>

KDF is "Key Derivation Function".
HKDF is designed as "General KDF" as RFC 5869 explicitly states in Section
4.


>
> 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
>

Again, RFC 5869 explicitly states it is a "General KDF". There are
specific examples, but there is _NO_ statement that defines HKDF
for specific purpose.

It even explains strange (but valid) KDF usage as CSPRNG.

My CSRF token example is obviously a good KDF application example.
What makes you think it is a bad one?


> 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.
>

"HKDF is intended for use in a wide variety of KDF applications."
Nothing wrong for using wide variety of KDF tasks.


> - 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.
>

Overkill? Not at all. Should I list reasons why advanced CSRF token by HKDF
is required/better?

I repeat an explanation in my PHP RFC.
NOTE: String concatenations have risk.

If moderately secure hashing is acceptable, one could use `hash()` for
URI specific CSRF token with expiration like

$csrf_token = hash('sha3-256', $csrf_token_seed . $expire_timestamp .
$the_uri);

This is obviously worse way because of the "String concatenation".
i.e. $csrf_token_seed . $expire_timestamp . $the_uri
Better way is not to concatenate string.

$csrf_token = hash_hmac('sha3-256', $csrf_token_seed, $expire_timestamp .
$the_uri);

This is still worse way because of the "String concatenation".
i.e. $expire_timestamp . $the_uri // Where $expire_timestamp is low
entropy salt.
Again, better way is not to concatenate string.

$csrf_token = bin2hex(hash_hkdf('sha3-256', $csrf_token_seed, 0,
$the_uri, $expire_timestamp ));



> - Is CSRF token generation what HKDF was made for? Absolutely NOT,
> and you know it.
>

Absolutely valid because it is "Designed as general purpose KDF".

Even though RFC 5869 explicitly states HKDF is not designed for "slow
hashing" like PBKDF2(hash_pbkdf2) or crypt(hash_password), it
could be used for password hashing _IF_ OKM and/or Salt could be
stored in _secure_ system(s). i.e. OKM and/or Salt could be stored
in other secure server(s).


> 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.
>

Did you read my reply to Nikita?
CSRF token is a "Authentication Key" that validates request is _authentic_.
Therefore, the CSRF example is one of a perfect HKDF application example
even with your claim "HKDF is for cryptographic task".

You insist HKDF is only for specific cryptographic tasks (I still don't
know
what you mean by this exactly. No valid examples yet.), how
_authentication_
can be non cryptographic task?


>> 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.
>

You don't prove any.

You only states "How RFC 5869 should be interpreted with your
understanding".

Previous `hash()`, `hash_hmac()` and `hash_hkdf()` example is a logical
explanation
why `hash_hkdf()`/HKDF is needed. i.e. String concatenations involve risks
even
with cryptographic hashes. Separating HMAC "Key" into "Salt" and "Info"
makes
HKDF useful to wide variety of applications. Optional "length" parameter
adds
more use cases which are rare.

RFC 5869's HKDF is made for general purpose KDF obviously. Does RFC
5869 limit or specify the usage? ABSOLUTELY NOT.

You seem misunderstood usage examples showed in RFC is the only HKDF
applications. You seem misunderstood common mistake warnings, too.


Your RFC lists multiple examples of using *user-provided plain-text
> passwords* for IKM, and you describe those as valid use cases as follows:
>
> 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.
>

I agree no KDF including HKDF will provide automatically secure keys by
itself.
This is the reason why the manual explicitly should state best practices
and
common mistakes. (And insisting "salt" as the first required parameter)

The explanations are warnings for "HKDF as slow hashing" and "non secret
salt".

Applications, that _must_ store "Salt" and "Resulted Hash"(OKM) in the
_same_ DB, must not use HKDF "as-is".

OKM and/or Salt must be stored in _secure_ system(s) when HKDF(or HMAC)
is used for user entered password. This is explained already in this mail.

"Non secret salt" never increase entropy. (This is common KDF application
mistake)
With HKDF, PRK must have enough entropy which attacker cannot guess
with reasonable computation time.
i.e. HMAC(IKM, Salt) must be secure.

Strong key derivations, that make strong encryption keys from poor keys
like
user entered password, are very _common_ tasks. Users must do whenever
it is possible.

e.g.
$secure_aes256_key = hex2bin(hash_hmac('sha3-256', $poor_user_password,
$strong_SECRET_salt));
OR with `hash_hkdf()`
$secure_aes256_key = hash_hkdf('sha3-256', $poor_user_password, 0, '',
$strong_SECRET_salt);

Salt obviously must be _SECRET_ (and have enough entropy), otherwise
simple brute force attack works.

I'm not sure how many times I showed this logically obvious example.

Random strong _SECRET_ salt does produce strong PRK regardless of IKM,
therefore increase OKM entropy. Explanation is omitted because it is
obvious.


> Is this FUD? Do we all still not understand HKDF, while you're the
> only person on the planet who does?
>

You are insisting false FUD that HKDF is for specific task(s) and valid
KDF usages as invalid. In this mail, you are insisting HKDF cannot
increase OKM entropy while random _secret_ salt can.

No cryptographers will recommend "Omitting salt", but recommend it
whenever it's possible.

No cryptographers will consider HKDF based advanced CSRF token as
invalid HKDF application.

If any, please let me know.

Anyway, salt as the last optional parameter is total nonsense, claim that
KDF
based CSRF as invalid HKDF application as well.

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.
>

Not everybody, I presume.
I don't see logically correct objections yet.

Regards,

P.S.
I've presented more than enough good HKDF usage examples that users
should/must provide proper salt in my PHP RFC.

You show _no_ examples that are valid/recommended/common HKDF
usage only with length and length/info. Please give some examples that
could be common and useful like advanced CSRF token by HKDF.

I don't need your view of HKDF RFC or usage, but I do need good practical
examples that justify your point of view. Please don't waste of your/my
time,
just give some good examples in next reply. Thanks.

--
Yasuo Ohgaki
yohgaki@ohgaki.net