<div dir="ltr"><div class="gmail_extra">On Tue, Aug 25, 2015 at 10:23 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><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">
I think the "noh" branch was too abstract and confusing, so I've been<br>
simplifying in the "noh2" branch. <br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div>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.</div><div>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.</div><div><br></div><div>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?). </div></div>
</div></div>