[noise] New draft: "916" branch

[Trevor Perrin]

On Mon, Sep 21, 2015 at 10:09 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> On Mon, Sep 21, 2015 at 9:32 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>>  * The first MixKey() step just does k = HASH(data), instead of k =
>> KDF(GETKEY(k, n), data).  That saves a KDF call and 3-4 SHA256
>> compression functions in typical usage.
>
>
>  "data" here is a DH calculation I believe. Is it safe to pass this simply
> to HASH()? I thought that Hugo's HKDF and related KDF functions were
> specifically designed to "stretch" non-uniform DH outputs, and a simple HASH
> is unsuitable for this. What's the idea here?

Without a random salt, HKDF's extract step just "falls back" to the
Random Oracle Model - HASH() is also secure in the ROM.

Once we have a key, we use HMAC is the same way HKDF extract does, so
can enjoy the same analysis if you want to make a stronger-than-ROM
argument.

The Noise KDF description didn't capture the nuance of the HKDF HMAC
analysis, and I guess it's possible people could make a stupid choice
here, or get confused, so I've changed the "symmetric crypto
parameters" to require HASH and HMAC-HASH (i.e.: you no longer get a
choice for KDF, the spec says to use HMAC).

If you want to do something different I don't particularly care.
(None of this matters: ECDH outputs are close to uniform, just about
any crypto hash would be good enough).  But forcing HMAC keeps things
simple, concrete, and stays consistent with the most-analyzed design
in this area.

Anyways, I merged this to master, I can back things out if needed, but
I'm pretty sure this is the best Noise:

https://github.com/trevp/noise/blob/master/noise.md


Trevor