[noise] New branch of Noise spec

[Trevor Perrin]

On Fri, Aug 21, 2015 at 6:09 PM, Jason A. Donenfeld
<jason.donenfeld at gmail.com> wrote:
> Hey Trevor,
>
> In the car headed on a backpacking trip, using my phone, so I'll give a
> proper reply and review on Tuesday when I'm home, but preliminary thoughts
> on smartphone reading:
>
> - Fission() for session derivation - do it once for one, and the other keeps
> the original kernel. This amounts to the same thing as before, right? Since
> getkey is called for n+1 and n+2 and the new sessions start at 0. So no real
> change here -- just wording. Is this correct?

The same except I realize the (initiator, responder) ordering got
flipped.  I should probably change it back.


> - In the old spec, when writing a handshake message, everytime there was an
> encrypted write, the entire prior contents of the message was put as ad to
> encrypt. My understanding was this was a clever way of preventing reordering
> attacks.

It's not about ordering, it's about making sure the encryptions "bind"
any important previous context.


> I didn't see this in the new spec, though I may have overlooked
> something on my smartphone. Is this because simply calling MixHash is
> sufficient?

Yes, MixHash() replaces that.


> Since the hash is authenticated at each step, and so if each
> message part is sequentially mixed in, we'll ensure ordering? If so, for any
> additional fields in the handshake messages, such as my timestamp at the
> end, can I MixHash it in safely?

Just put your fields in the payload, and they'll be associated with
any later encryptions.


> Also, if so, I didn't see MixHash mentioned
> with WriteEphemeral. Is that because it's dangerous to call MixHash on non
> secret data?

No, it's because static public keys and payloads might be important
context, but ephemeral public keys are not - if someone can fiddle a
static public key into an equivalent-but-different value we want to
detect that, but we don't care if they do that to ephemeral public
keys.  So I didn't want to waste MixHash() calls.


> In any case, one downside is that any prologue or prepended
> message type or transmitted explicit nonce isn't reorder-resistant, unless
> those too are kosher for calling MixHash on. Personally I'd like to mix
> every part of the message into h as I write it, and then put h as ad for
> each encryption.

The handshake shouldn't need explicit nonces.  Prepended message types
are taken care of by the "branch number", and branching will re-mix
the key.

If we add a MixHash() for prologue data, then it will always need to
be called, even with zero-length prologue, so that's wasting a few
more MixHash() calls.


> - You clear h before sending application messages, and then it appears that
> h isn't touched again. That means application messages don't make use of the
> ad param, right?

Right.


> That's a nice simplification. Any downsides to it?

A bit more complicated, since you have to clear the value.


> Presumably the derived key already ties the application session to the
> parent handshake session, so carrying over the h value doesn't really add
> much except more work for poly.

Right, since the last handshake message will mix the key, any messages
that use that key must be send by someone who sent or received the
last handshake message, thus saw the correct h value.


Trevor