[noise] BLAKE2X as KDF

[Brian Smith]

Trevor Perrin <trevp at trevp.net> wrote:
> 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..

One option that might address the above concerns would be to
parameterize the key derivation function not as HKDF(hash) but as
Extract-then-Expand(mac). This is actually how HKDF is defined in [1],
"Extract-then-Expand KDF and a HMAC-based Instantiation." This would
allow the use of Keyed BLAKE2 instead of HMAC, but would not admit
using BLAKE2X. It would also allow the use of AES-CBC-MAC instead of
HMAC(hash). (Note I've seen other proposals to use
Extract-then-Expand(AES-CBC-MAC) instead of HKDF.)

>  * 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).

I imagine most BLAKE2 implementations are going to implement at least
Keyed BLAKE2 in addition to the unkeyed version. However, I have to
admit I don't see a significant advantage of BLAKE2X over
Extract-then-Expand(Keyed BLAKE2). I imagine that crypto library
maintainers would rather not add a bunch of BLAKE2-specific code and a
bunch of SHA-3 specific code to do things the same-way-but-different
as how things are currently being done with SHA-2, unless there are
really significant advantages to the new ways.

Anway, if I already have AES-CBC-MAC and AES-CCM (or even AES-CBC-AMC
and AES-GCM) in hardware, it would be unfortunate to have to make a
software HMAC just to get a KDF, even though HMAC is admittedly very
simple. Of course, if it were possible to avoid HMAC then I'd also
want to find a way to avoid needing a hash function at all just for
the handshake hash.

Cheers,
Brian
-- 
https://briansmith.org/