[noise] Notes and nits

[Trevor Perrin]

On Fri, Jun 26, 2015 at 6:54 PM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> Thanks for the clarifications. A big help.
>
> On Sat, Jun 27, 2015 at 1:33 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> Nonces are 64 bits in length because:
>>  * Some ciphers (e.g. Salsa20) only have 64 bit nonces
>>  * 64 bits allows the entire nonce to be treated as an integer and incremented
>>  * 96 bits nonces (e.g. in RFC 7539) are a confusing size where it's
>> unclear if random nonces are acceptable.
>
> Interesting. IIRC, ChaCha20 really uses a 128 bit nonce per block,
> which RFC7539 then partitions into 96 bits of random data and a 32 bit
> block counter. It might make sense to go back to using a 64 bit block
> counter for noise, perhaps.

RFC 7539 will be in TLS, thus OpenSSL, NSS, etc. So I think it's best
to use that instead of redefine it, but just set 32 bits of the nonce
to zero and use the remaining 64 bits.


>>> Also - why hmac-sha2-512? Why not BLAKE2b? Wouldn't using BLAKE2b
>>> simplify this even more? Extremely interested to hear your feedback
>>> here about this.
>>
>> Changed to SHA2-256 since we only need 32 bytes output and it's a
>> smaller function:
>>  * SHA2 is widely available
>>  * SHA2-256 requires less state and produces a sufficient-sized output
>> (32 bytes)
>
> Curious -- didn't realize that about state requirements. It looks like
> blake2b is considerably faster though: <https://blake2.net/sandy.png>.
> The appealing part is that HMAC isn't required, as Blake2b by default
> accepts a "key" parameter as well as the usual input parameter.

Speed doesn't matter much for the handshake hashing and key
derivation.  HMAC and SHA2 are in most modern crypto libraries, BLAKE2
isn't.  But you can certainly define ciphersuites that use BLAKE2.


>> The session nonce `n` is incremented after every encryption or decryption operation.
>
> For a udp-based protocol, the nonce will need to be included with each
> message, because messages are prone to arriving out of order or not
> arriving at all, and then a window will be specified for decryption of
> how far back from the greatest nonce it's willing to accept. IOW, it's
> used as a counter to avoid replay attack. (Side note: does that mean
> it should be part of authtext? Or does being a nonce to the cipher
> already ensure that it's authenticated?) So it's accurate to say that
> `n` needs to be incremented after every encryption. But for
> decryption, since the nonce is included, really what needs to happen
> is "set the local nonce to the received nonce if the received nonce is
> greater," and not simply "increment the nonce".

Yeah, I think that sort of nonce handling will have to be defined at a
higher level than the Noise core spec - e.g. your protocol can put a
nonce in the prologue, and then say that before processing the Noise
message, the prologue is read and used to set the nonce in the Noise
session.


Trevor