[noise] Nonce Post-Increment vs Pre-Increment

[Jason A. Donenfeld]

On Mon, Nov 9, 2015 at 11:48 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> Couldn't you just as easily store the _next_ counter you haven't received?
>
> This seems like an arbitrary choice.  Maybe IPsec sequence numbers
> start at 1, but TLS (and DTLS) start at 0, e.g. DTLS RFC 5347: ("This
> counter is initialy set to zero [...] DTLS implementations maintain
> (at least notionally) a next_receive_seq counter").

Looking at the openssl implementation, they actually use the exact
same algorithm as me, which doesn't work for 0 nonces. In openssl, the
first message (seq=0) is simply special cased, since reception of it
triggers the creation of a new connection etc. Ugly but whatever.

There are some solutions for supporting the bitmap with 0-based nonces:

1. Special case zero, adding more state.
2. Do as you say and store the next counter, and then rewrite the rest
of the algorithm to work with this. The result is more complicated
than the original one. It also imposes a limitation on the biggest
nonce, making it 2^64 - 1, since the "next counter" needs to not wrap.
3. Simply use the algorithm as is, put add 1 to the nonce before
processing. This seems like the simplest solution. It too imposes a
limitation on the biggest nonce, making it 2^64 - 1, since we're
adding 1 and this needs to not wrap.

Since the 2^64 - 1 thing happens anyway with 1-based nonces, I guess
I'll go with option (3).

> The case where you have multiple threads contending to send out the
> next transport message is already pretty complicated.

Wait, why? Are there additional cryptographic concerns I should have?
Right now I just make sure the nonce is an atomic variable, and then
pump out messages willy nilly, which is rather simple. Hopefully I'm
not missing something crucial that I need to serialize... Cache-timing
attacks against concurrent decryptions that I need to protect against
or something?