<div dir="ltr">Hey Trevor,<div><br></div><div class="gmail_quote"></div><div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Oct 13, 2015 at 9:23 PM Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You could also check out (or join!) our mailing list:<br>
<br>
<a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a><br>
<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Subscribed! Will be happy to contribute if I can.</div></div></div><div dir="ltr"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> From: Jean-Philippe Aumasson <<a href="mailto:jeanphilippe.aumasson@gmail.com" target="_blank">jeanphilippe.aumasson@gmail.com</a>><br>
><br>
> A KDF as defined in Krawczyk paper (and in SP 800-108) is essentially<br>
> a PRF with variable-size output: it takes as input a key and returns<br>
> key material that's typically longer than the given key. HKDF achieves<br>
> this by iterating calls to a PRF.<br>
<br>
Well, in HKDF there's an "extract" phase followed by an "expand"<br>
phase.  Certainly the "expand" is easily accomplished by a PRF.  But<br>
much of the HKDF paper is about extraction under different<br>
assumptions.  For example, Section 6 has several lemmas based on the<br>
NMAC / HMAC structure.<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>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.</div><div><br></div><div>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.<br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
HKDF has been widely adopted (e.g. IPsec, TextSecure, TLS 1.3, QUIC).<br>
The use being considered is just processing a few DHs, so is not a<br>
performance bottleneck.  So I still think the most conservative and<br>
easy-to-defend choice would just use the hash function (whether SHA2,<br>
SHA3, BLAKE2, etc) within the HKDF / HMAC framework.<br>
<br></blockquote><div><br></div></div></div><div dir="ltr"><div class="gmail_quote"><div>Agree. Maybe also check any potential side–channel leakage of the selected scheme and its implications (like internal state leak, etc.). </div><div><br></div><div> </div></div></div></div>