[noise] Fwd: BLAKE2 as a diffie-hellman entropy extractor

[Jean-Philippe Aumasson]

Hey Trevor,

On Tue, Oct 13, 2015 at 9:23 PM Trevor Perrin <trevp at trevp.net> wrote:

> You could also check out (or join!) our mailing list:
>
> https://moderncrypto.org/mailman/listinfo/noise
>
>
Subscribed! Will be happy to contribute if I can.


>
> > From: Jean-Philippe Aumasson <jeanphilippe.aumasson at gmail.com>
> >
> > A KDF as defined in Krawczyk paper (and in SP 800-108) is essentially
> > a PRF with variable-size output: it takes as input a key and returns
> > key material that's typically longer than the given key. HKDF achieves
> > this by iterating calls to a PRF.
>
> Well, in HKDF there's an "extract" phase followed by an "expand"
> phase.  Certainly the "expand" is easily accomplished by a PRF.  But
> much of the HKDF paper is about extraction under different
> assumptions.  For example, Section 6 has several lemmas based on the
> NMAC / HMAC structure.
>

The extract-then-expand approach is a way to achieve KDF properties, but
not the only way to do so. For example, the Keccak authors proved how to
build a KDF using the sponge function, which yields simpler constructions
than HKDF.

As it is, keyed BLAKE doesn't provide variable–length output—it's just a
PRF—but you can use HKDF to build one by instantiating its PRF with
BLAKE2's.

HKDF has been widely adopted (e.g. IPsec, TextSecure, TLS 1.3, QUIC).
> The use being considered is just processing a few DHs, so is not a
> performance bottleneck.  So I still think the most conservative and
> easy-to-defend choice would just use the hash function (whether SHA2,
> SHA3, BLAKE2, etc) within the HKDF / HMAC framework.
>
>
Agree. Maybe also check any potential side–channel leakage of the selected
scheme and its implications (like internal state leak, etc.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20151013/d1f3ab42/attachment.html>