[noise] Notes and nits

[Jason A. Donenfeld]

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. 96 bits *is* confusing though. It looks
like the intention is from RFC5116, where 32 bits are supposed to be
specific to the sender when sending keys are shared.


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


>
> I'll have to add a treatment of that later, right now I'm just trying
> to get down the protocol mechanics.

Okay.

> h: A hash output from the hash algorithm specified in the ciphersuite. This
> hashes data used in a Noise protocol, and is included as additional
> authenticated data for encryption.
>  4) If the descriptor was not empty, `h` is set to `HASH(h || message)`.

Thanks for clarifying that. Makes sense now -- it's used as the
authtext param. And it's only updated during the handshake, but not
subsequently during data transmission (otherwise - trouble for udp).


> 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".