[noise] New branch: hkdf

[Kenton Varda]

On Sat, Oct 10, 2015 at 12:21 PM, Trevor Perrin <trevp at trevp.net> wrote:

> But assuming well-optimized code:  If the HKDF version is, say, 8-9
> HMACs slower, then it's hashing an extra ~2000 bytes (with SHA256).
> To put very rough numbers on it, that might be 20K Haswell cycles [1].
> Compared to 3 ECDHs + 1 keygen at ~500K cycles [2], this is < 5% speed
> difference for the handshake.
>

FWIW, as a system builder but not a cryptographer, dismissing 5% speed
losses makes me uncomfortable, for a couple reasons:

- Slow systems often come from a series of decisions that 5% here and 5%
there don't really matter. Eventually it adds up.

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

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

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

-Kenton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20151013/7002e3b9/attachment.html>