[noise] New branch of Noise spec

[Jason A. Donenfeld]

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?

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

- 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? That's a nice simplification. Any downsides to it?
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.

Okay that's all for now as it's 3am and we're about to drive over some
super dangerous mountain pass and I should probably pay attention. I'll
read more closely on Tuesday.

Jason
On Aug 22, 2015 1:33 AM, "Trevor Perrin" <trevp at trevp.net> wrote:

> Hi,
>
> I've been preparing a new branch of Noise, with most text rewritten
> and some substantive changes:
>
> https://github.com/trevp/noise/blob/noh/noise.md
>
>
> Probably could use some text polishing, but I wanted to get this out
> for feedback, so please send some!
>
>
> Terminology changes:
>
>  * Instead of Box / Handshake distinction for one-shot or interactive
> handshakes, now there is a Handshake / Application message
> distinction, and within the Handshake a One-way vs Interactive
> distinction.
>
>  * The symmetric-key crypto is encapsulated into a "kernel" object.
> The main benefit is ease of presentation, but this might also make it
> clearer how to swap in new symmetric-key crypto like sponges.
>
> Main changes:
>
>  * Handshake hashing was a weird mix of hashing completed messages,
> plus using AAD to cover partial messages.  This meant repeatedly
> authenticating or hashing the same data.  Also, the hashes were left
> around for the lifetime of the session.  The new system only hashes
> relevant fields, once, and stops authenticating the hash after the
> handshake.
>
>  * A notion of "branching" has been added so you can specify how to
> branch between different versions, or ciphersuites, or handshake
> patterns.
>
>  * Prologue had an unclear purpose, so was removed.  If you want to
> send plaintext data during an early handshake message, just use the
> payload.  If you want to send a version or type indicator, use
> branching.
>
>  * The "conventions" I mentioned earlier have been added, including
> framing and padding fields.  Also, handshake messages use an extension
> system that allows one party to offer support for new things that will
> be ignored by older implementations.
>
>  * I've fleshed out a range of ways to send application messages,
> allowing for forward-secure key updating / ratcheting, and explicit
> nonces.
>
>  * Ciphersuites have been separated into "DH functions" and a
> symmetric-key "cipherset", since there was no reason to tie these
> together.
>
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150822/5e5cac3f/attachment.html>