Hi, On Tue, Apr 25, 2017 at 3:28 AM, Yasuo Ohgaki <yohg...@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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
