Hi Nikita,

On Fri, Apr 14, 2017 at 6:24 PM, Nikita Popov <nikita....@gmail.com> wrote:

> Strong -1 on these docs changes. They are wrong and they will confuse
> users about when and how HKDF should be used.
>
> I have no idea where you got the idea that HKDF is supposed to be used for
> CSRF token generation, but it isn't. I did not check whether your code is
> correct and secure, but CSRF token generation is certainly not a common or
> typical application of HKDF and as such should not be present in the
> documentation.
>
> Your "bad example" is actually pretty much the textbook use-case for HKDF.
> The way you wrote it (get a AES-256 key from an AES-128 key) doesn't make
> much sense, but the general principle of extracting two keys (for
> encryption and authentication) from a single key is one of *the* use-cases
> of HKDF. It is also, contrary to your statement in the documentation
> snippet, perfectly cryptographically sound. A salt is not required for this
> case. A salt *may* be beneficial, but for entirely different reasons (as
> Scott pointed out, for many block cipher modes fixed encryption keys only
> have a lifetime of around 2^64 encryptions, past which point IV collisions
> are to be expected -- a salt in key derivation could mitigate this.)
>

It seems you consider HKDF as very specific function for very specific
crypt task
which is wrong by the RFC 5869 intention.
The RFC 5869 explicitly mentions as

  4.  Applications of HKDF
   HKDF is intended for use in a wide variety of KDF applications.

Why we must limit HKDF usage for certain crypt tasks even if it is
designed for _general_ Key Derivation tasks?

Key derivations in authentication is very common task.
CSRF token is "Key that validates the _authentic_ request".
It is obvious that expiration enabled URI specific CSRF token is
a lot secure than common static CSRF tokens that are valid for all requests.
How this could be bad example?

128 bit entropy key for AES 256 is simply bad practice like
$aes256key = hash('sha256', 'mypassword', true);

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

Reply via email to