[noise] New branch: hkdf

[Trevor Perrin]

On Wed, Oct 14, 2015 at 6:11 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Wed, Oct 14, 2015 at 7:25 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> The HKDF paper and spec consider using the output from HKDF-Extract
>> directly, without HKDF-Expand.  But they don't recommend it:
>
> Thanks for pointing that out; I had overlooked these sections
> (although they don't exactly make the most compelling arguments...).

I don't think there's going to be a compelling argument on any side
here, there are many ways of doing the key derivation that would
probably be fine.

But a strong key derivation is crucial to Noise, particularly because
it's used for authentication, so an attacker might try mixing known
values with unknown ones to influence the final key.  We need to
convince people that's not possible.  HKDF brings the reassurance of a
widely-studied and widely-used design, and takes a very conservative
approach that migh even survive some hash weaknesses (due to inner +
outer hashing, and extract + expand hashing).  The benefits seem to me
to outweigh the cost of a few percent of compute speed.

So I'm still inclined to go with the HKDF branch, but I'll leave this
open for any more arguments for a few days.


Trevor


>
>>
>> https://eprint.iacr.org/2010/264.pdf, Appendix D:
>> """
>> when SKM is from a source or form that requires the use of the
>> extraction step but the number of key-material bits required is no
>> larger than the output PRK of the extractor, one could use directly
>> this key as the output of the KDF. Yet, in this case one could still
>> apply the PRF* part as an additional level of “smoothing” of the
>> output of XTR. In particular, this can help against potential attacks
>> on XTR since by applying PRF* we make sure that the raw output from
>> XTR is never directly exposed.
>> """
>>
>> RFC 5869, 3.3:
>> """
>> In the case where the amount of required key bits, L, is no more than
>> HashLen, one could use PRK directly as the OKM.  This, however, is NOT
>> RECOMMENDED, especially because it would omit the use of 'info' as
>> part of the derivation process (and adding 'info' as an input to the
>> extract step is not advisable -- see [HKDF-paper]).
>> """
>
> Are we using the info param?

No, but that's not the only reason he argues for HKDF-Expand.

Trevor