[noise] KDF, part 9281274

[Trevor Perrin]

On Fri, Apr 22, 2016 at 8:18 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> What precisely would be wrong about greatly simplifying and
> speeding-up the whole thing by defining KDF either as:
>
> output = BLAKE2b-PRF(key, input)
> return (output[0:31], output[32:63])
>
> or
>
> output = HMAC-SHA2-512(key, input)
> return (output[0:31], output[32:63])


Sure, that works.  With a good hash, basically anything that hashes
the inputs into the outputs works.

I don't think fixing a 512-bit hash with 256-bit chaining key is the
best option, though.  I prefer the current design's allowance for
256-bit hashes, and getting a full 512-bits chaining key with a
512-bit hash.

I also don't think optimizing here gains much.  If you've done timing
comparisons that show otherwise, that would be good to see.


There's a thousand different ways we could do key derivation, all with
slightly different performance / analysis properties.

I don't think any alternatives are going to be dramatically better
than what we have now, which enjoys:
 - simple analysis in the ROM (since we just hash everything together)
 - simple description as HKDF(salt=chaining_key, ikm=new_material)

But I'll write up some analysis of alternatives in the next few days,
so we can vet the KDF design one more time.


Trevor