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 <div class="gmail_quote">On Aug 22, 2015 1:33 AM, "Trevor Perrin" <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I've been preparing a new branch of Noise, with most text rewritten and some substantive changes: <a href="https://github.com/trevp/noise/blob/noh/noise.md" rel="noreferrer" target="_blank">https://github.com/trevp/noise/blob/noh/noise.md</a> 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 <a href="mailto:Noise@moderncrypto.org">Noise@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a> </blockquote></div>