[noise] Nonce Post-Increment vs Pre-Increment

[Trevor Perrin]

On Mon, Nov 9, 2015 at 5:42 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> 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.

It's not clear to me that changing the algorithm to store the next
count makes it any more complicated?


>> 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?

I just meant that subtracting 1 to convert 1-based sequence numbers
(your preference) to 0-based didn't seem a big deal, in the scheme of
things.

Trevor