[noise] BLAKE2X as KDF

[Trevor Perrin]

On Sun, Dec 25, 2016 at 10:14 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Hey Trevor,
>
> I thought I'd revisit this, now that https://blake2.net/blake2x.pdf is
> finished. From the looks of this specification, it seems exactly
> designed as a replacement for HKDF. Not only does it give a speedup,
> but it also makes Noise easier to implement, since it seems feasible
> that Blake2 libraries won't have an HMAC function. It seems like the
> change to Noise would be fairly straight-forward too. If you're using
> one of the SHA2 modes, you use HKDF. If you're using one of the Blake2
> modes, you use Blake2x. Each function family with its associated KDF.


My opinion here hasn't changed:

 * Noise's core design, including the chain-of-HKDF for key
derivation, has been unchanged since 2015.  There's a lot of benefits
to a stable design for implementers and analysis, so I don't think we
should make changes without a very strong reason.

 * HKDF and HMAC are conservative designs.  BLAKE2 is a fairly new
hash (~4 years old) designed for high speed, so I'm happy to use it in
a conservative way.  The performance impact of using HKDF here is very
small, as handshake time is dominated by public-key ops.

 * HKDF and HMAC are widely used for KDF (Signal, Noise, IPsec, TLS
1.3), so this has been subjected to a lot of analysis, and will
continue to receive analysis.  This also means people have a comfort
level with HKDF which makes the design easy to explain and justify.

 * Having a simple interface to crypto primitives makes it easy to
plug in new primitives without complicated design and analysis.  E.g.
it's easy to define Noise over SHA2, SHA3, BLAKE2, or others.  It
would be harder if each hash used a custom KDF..

 * You suggest that Keyed BLAKE2x will be easier to implement than
HMAC/HKDF, if libraries don't have an HMAC function.  But HKDF is easy
to implement given any hash (e.g. BLAKE2).  BLAKE2X requires modifying
the BLAKE2 internals to change the parameter block, which could be
difficult (e.g. if you have a hardware core or assembly code that
implements BLAKE2 but not Keyed BLAKE2X).

This isn't Noise-related, but I see elsewhere in WireGuard you're
considering replacing ChaCha20/Poly1305 with XChaCha20/Poly1305 [1].
I think the previous bullet point also applies here:  It seems easier
to just use HMAC(key, random_nonce) to produce a fresh random key,
instead of modifying the internals of ChaCha20/Poly1305.

Trevor

[1] https://lists.zx2c4.com/pipermail/wireguard/2016-December/000838.html