[noise] New draft: "noh2" branch

[Jason A. Donenfeld]

On Tue, Aug 25, 2015 at 10:23 AM, Trevor Perrin <trevp at trevp.net> wrote:

> I think the "noh" branch was too abstract and confusing, so I've been
> simplifying in the "noh2" branch.
>

FWIW, I prefer master to noh, and I prefer noh to noh2. Noh2 and noh seem
to add quite a bit of complexity and implementation prescription that I
don't openly welcome. Whereas the master branch was a pleasure to implement
-- and only took about an hour -- I really would rather not implement
noh/noh2.

What I like about the new branches: h is not used for transport data
messages, so aad is empty, which means I have a few bytes less of Poly to
compute. This is somewhat important to me because this is in the hot path,
so every cycle of savings matters.

What I dislike: the considerable complexity and abstraction added.  While
elegant, in fact I don't want the ability for "parties to alter handshake
patterns, ciphersets, and transport flags on the fly". This might make
noise suitable as a general purpose TLS-rank protocol, but I'm after
something small, minimal, secure, and easy to produce an audit-able
implementation. I don't want it to have so many bells and whistles that I
need to write it in Rust or Haskell to have faith in my code; instead I
want to write C that I can confidently verify without my eyes bleeding.
I also liked the quality of the master branch where all previous bytes were
in aad for each encryption, which imposed ordering constraints (in addition
to binding relevant data to the exchange). It also had the nice effect of
authenticating the prologue, which seems like a nice quality, as I wouldn't
want an attacker to be able to "break apart" any components of one message
and put them in a message of another type.
The general writing of noh2 is also a bit difficult. I don't want
implementation details like this. I'd rather have a clear picture of how
it's constructed, and then figure out the best way to implement this. The
reason is that different environments require different programming flows,
which might require a particular idea to be implemented in a way that's not
the most obvious logic; for example, in the kernel, supporting RCU for
lock-less data structures often results in some slightly different flows.
As such, I prefer master and noh's description to noh2's.

So I think that if things move ahead with noh/noh2, I'm going to depart
slightly from Noise and produce my own thinger, based on current master's
HandshakeIK with the addition of a TAI64N timestamp in the first message to
prevent replay attacks. Then, I'll get rid of both h and the
all-previous-bytes aad business, and replace it with mixing in each DH
result and each written chunk into k, which should further simplify things
and provide a speed benefit, without, so far as I can see, introducing any
extra vulnerabilities (hopefully?).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150827/88dde0cd/attachment.html>