<div dir="auto"><div><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Dec 27, 2016 20:20, "Trevor Perrin" <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="quoted-text">On Mon, Dec 26, 2016 at 4:31 PM, Brian Smith <<a href="mailto:brian@briansmith.org">brian@briansmith.org</a>> wrote:<br>
> Trevor Perrin <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote:<br>
>><br>
>>  * Noise's core design, including the chain-of-HKDF for key<br>
</div>>> derivation, has been unchanged since 2015. [...]<br>
>><br>
>>  * HKDF and HMAC are conservative designs. [...]<br>
<div class="quoted-text">>><br>
>>  * HKDF and HMAC are widely used for KDF (Signal, Noise, IPsec, TLS<br>
</div>>> 1.3),  [..]<br>
<div class="quoted-text">>><br>
>>  * Having a simple interface to crypto primitives makes it easy to<br>
</div>>> plug in new primitives without complicated design and analysis. [...]<br>
<div class="quoted-text">><br>
> One option that might address the above concerns would be to<br>
> parameterize the key derivation function not as HKDF(hash) but as<br>
> Extract-then-Expand(mac). This is actually how HKDF is defined in [1],<br>
> "Extract-then-Expand KDF and a HMAC-based Instantiation."<br>
<br>
</div>HKDF is more complicated than that:<br>
<br>
 * The Extract-then-Expand concept requires an entropy extractor<br>
(Extract) followed by a PRF (Expand).  A MAC is not necessarily either<br>
of those things.<br>
<br>
 * HKDF is defined on top of HMAC, not an arbitrary MAC (e.g. the<br>
analysis in Section 6 of the HKDF paper uses HMAC's outer and inner<br>
functions, and in Sections 5 and 6 it discusses modelling the<br>
underlying hash as a Random Oracle).<br>
<br>
 * Noise uses HKDF within a multi-stage KDF, so the "salt" is not just<br>
for randomizing Extraction, but is also used to accumulate previous<br>
inputs, so we have additional requirements, e.g. we'd like the<br>
function to be a PRF if keyed by either the salt or input key<br>
material, or at least to be a Random Oracle if the underlying hash is<br>
a Random Oracle (see discussion / security model at [1]).  Polynomial<br>
MACs (like GCM and Poly1305) don't meet these requirements.<br>
<div class="quoted-text"><br>
<br>
>>  * You suggest that Keyed BLAKE2x will be easier to implement than<br>
>> HMAC/HKDF, if libraries don't have an HMAC function.  But HKDF is easy<br>
>> to implement given any hash (e.g. BLAKE2).  BLAKE2X requires modifying<br>
>> the BLAKE2 internals to change the parameter block, which could be<br>
>> difficult (e.g. if you have a hardware core or assembly code that<br>
>> implements BLAKE2 but not Keyed BLAKE2X).<br>
><br>
> I imagine most BLAKE2 implementations are going to implement at least<br>
> Keyed BLAKE2 in addition to the unkeyed version. However, I have to<br>
> admit I don't see a significant advantage of BLAKE2X over<br>
> Extract-then-Expand(Keyed BLAKE2). I imagine that crypto library<br>
> maintainers would rather not add a bunch of BLAKE2-specific code and a<br>
> bunch of SHA-3 specific code to do things the same-way-but-different<br>
> as how things are currently being done with SHA-2<br>
<br>
</div>I'd extend that same argument to preferring HMAC-BLAKE2 over keyed<br>
BLAKE2, in this use case.<br>
<br>
Keyed BLAKE2 is just a key-prepend MAC, and HMAC is just a nested pair<br>
of key-prepend MACs, so HMAC is a bit slower but more conservative and<br>
means we have a consistent structure, which simplifies design /<br>
implementation / analysis for all hashes, instead of needing custom<br>
effort for each.<br>
<div class="quoted-text"><br>
<br>
> Anway, if I already have AES-CBC-MAC and AES-CCM (or even AES-CBC-AMC<br>
> and AES-GCM) in hardware, it would be unfortunate to have to make a<br>
> software HMAC just to get a KDF, even though HMAC is admittedly very<br>
> simple. Of course, if it were possible to avoid HMAC then I'd also<br>
> want to find a way to avoid needing a hash function at all just for<br>
> the handshake hash.<br>
<br>
</div>Well, we already need a HASH() function for "h", so I don't think<br>
we're going to eliminate that, or build it on top of an AEAD.<br>
<br>
If you want to unify all symmetric crypto around a single primitive<br>
maybe a sponge could be used, but that would require re-defining the<br>
entire SymmetricCrypto layer of Noise.  Which could be done, but I'm<br>
not sure the practical advantages would be that significant (smaller<br>
code size, but not necessarily faster or less RAM use).<br>
<br>
Anyways, I definitely need to add a rationale section about this, but<br>
I'm still quite happy with the current KDF design, and I think there's<br>
enough implementation support (WhatsApp, WireGuard, various libraries)<br>
that we should consider it frozen.<br></blockquote></div></div></div><div dir="auto"><br></div><div dir="auto">WireGuard certainly isnt YET frozen.</div><div dir="auto"><br></div><div dir="auto">WhatsApp aggressively pushes updates, has unlimited funding, and isnt even open source or willing to tolerate third-party implementations.</div><div dir="auto"><br></div><div dir="auto">Other libraries have few consumers and have change-ready authors on this list.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Trevor<br>
<br>
[1] <a href="https://moderncrypto.org/mail-archive/noise/2016/000599.html" rel="noreferrer" target="_blank">https://moderncrypto.org/mail-<wbr>archive/noise/2016/000599.html</a><br>
</blockquote></div><br></div></div></div>