<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 10, 2015 at 12:21 PM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">But assuming well-optimized code:  If the HKDF version is, say, 8-9<br>
HMACs slower, then it's hashing an extra ~2000 bytes (with SHA256).<br>
To put very rough numbers on it, that might be 20K Haswell cycles [1].<br>
Compared to 3 ECDHs + 1 keygen at ~500K cycles [2], this is < 5% speed<br>
difference for the handshake.<br></blockquote><div><br></div><div>FWIW, as a system builder but not a cryptographer, dismissing 5% speed losses makes me uncomfortable, for a couple reasons:</div><div><br></div><div>- Slow systems often come from a series of decisions that 5% here and 5% there don't really matter. Eventually it adds up.</div><div><br></div><div>- Asserting that performance of one component doesn't matter because it is dwarfed by some other connected component implies a strong coupling between these components and may be a problem if someone wants to reuse the first component in some other context some day. Specifically, in this case, I wonder what will happen when I use Noise as a transport for Cap'n Proto, which emphasizes fast, live introductions (where one party instructs two other parties to start a session). It's conceivable that an introduction can be done securely with no asymmetric crypto (by having the introducer provide key material, if MITM by the introducer is a non-threat as in Cap'n Proto), and in high-performance cluster scenarios I can imagine the ability to avoid ECDH ops on every introduction being valuable. With the ECDH out, the slower KDF becomes more significant, possibly dominating connection setup.</div><div><br></div><div>I'm not personally qualified to judge the relative security risks of HKDF vs. the n0 approach. But the impression I get is that the change is trading off performance mainly for familiarity, with no belief that the n0 approach is flawed. That seems a bit sad to me, and it tempts me to diverge from the spec for Cap'n Proto's use case. It sounds like Jason is tempted to diverge as well. It may be worth trying to avoid providing temptations to the performance-addicts among us. :)</div><div><br></div><div>Also, FWIW, as a non-cryptographer I find the HKDF approach significantly less intuitive than the n0 approach, which I guess is ironic since HKDF is supposed to be more intuitive to cryptographers. I find myself wondering: "Isn't extracting entropy in a non-reversible way exactly what a stream cipher does? Why use all these HMACs instead?" (You say it is "unintuitive to call an encryption<br>function as part of the key derivation" but this is not my sense.) But not being a cryptographer, my notion of what's intuitive is probably flawed.</div><div><br></div><div>-Kenton</div></div></div></div>