Hi Niklas, On Fri, Sep 8, 2017 at 4:57 PM, Niklas Keller <m...@kelunik.com> wrote:
> Note for others: "The extract step in HKDF can concentrate existing >> entropy >> but cannot amplify entropy." is not came from the RFC. If a RFC states >> this I would be stunned. Please read on you'll see the evidence. >> > > This is ridiculous. Be stunned. It's right in the section about > applications of HKDF: https://tools.ietf.org/html/rfc5869#section-4, in > the middle of the second paragraph. > > Please stop, it's enough. > This is my bad I didn't understand "amplify" well. I mixed up "add" and "amplify" I admit this. However, the reason why I mixed up is Andrey's misunderstanding about HMAC nature. Andrey's words. ------ 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. ------- Following is wrong by HMAC nature. ------- it should NOT be relied upon to produce strong outputs from weak inputs ------- Who would think resulting $hash of following is insecure? $hash = hash_hmac('sha256', $weak_msg, $strong_key); RFC-5689 - https://tools.ietf.org/html/rfc5869#section-4 --------- One significant example is the derivation of cryptographic eys 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. --------- This whole sentence means HKDF cannot be used like PBKDF2. That's all. This is does not support Andrey's statement ------- it should NOT be relied upon to produce strong outputs from weak inputs ------- Instead, he should read this section. RFC 5689 - https://tools.ietf.org/html/rfc5869#section-3.3 -------- In some applications, the input key material IKM may already be present as a cryptographically strong key. In this case, one can skip the extract part and use IKM directly to key HMAC in the expand step. --------- "one can skip the extract part" is "one can omit salt". Obviously, the RFC is prepared for weak keys and it is perfectly OK to use weak keys unlike Andrey statement. If IKM should be strong always, HKDF would NOT have salt at all. However, HKDF has salt. Weak IKM is explicitly allowed by HKDF definition. Andrey, sorry for my confusion, but your claim is wrong by HKDF (HMAC) definition still. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
