[noise] New branch: hkdf

[Stephen Touset]

I myself gave this argument over a year ago, with previous designs. However,
given the current iteration of the spec model, I’m with Jason. The addition of
another key reduces the elegance of the spec, but in a practical sense it also
adds more unnecessary crypto.

The simplification to MixKey was a great change, in that it removed unnecessary
complication at the expense of only an extra hash operation once in the handshake.
This change, in contrast, adds complexity and makes the spec less clear.

> On Oct 2, 2015, at 6:00 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> https://github.com/trevp/noise/blob/hkdf/noise.md
> 
> Offlist I've gotten feedback: Why not just use HKDF for key
> derivation, since everyone else does: (QUIC, TLS 1.3, IPsec).
> 
> The current design is elegant in that it doesn't need separate cipher
> keys or chain keys, and it can be optimized to a pretty minimal amount
> of hash / cipher ops.
> 
> The counter-argument is:
> * Everyone else uses HKDF, so it's going to be harder to make people
> comfortable with a different design, and we don't benefit from the
> analysis and review that HKDF gets
> * These micro-optimizations don't matter
> * The GETKEY() construct adds a bunch of complexity to explain that
> we're using the AEAD, but also allowing you to skip the AEAD and just
> use the cipher
> 
> So I spec'd out an HKDF version.  Let's consider this and see if we prefer it.
> 
> 
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise

-- 
Stephen Touset
stephen at squareup.com