[noise] Notes and nits

[Michael Hamburg]

Hi Trevor,

I haven’t made a thorough pass through your spec yet, but I’m a little concerned by
your use of KDF(GETKEY(k,n),input) as a key update mechanism.  My concern is
that GETKEY(k,n) calls ENCRYPT, which is counter mode, so that it is exposed if
the other party encrypts anything with k,n.  So you will have to prevent attaks where,
eg, Alice sends a block of known plaintext:

ciphertext = known ^ Chacha(k,n), MAC

while Bob runs KDF with something weak (eg an attacker-supplied ephemeral DH):

k <- KDF(GETKEY(k,n), weakinput)

The attacker knows GETKEY(k,n) = known ^ ciphertext, and also knows weakinput,
so she now controls the channel.

This might not actually be possible in noise as written, but I’d be very careful to make
sure.  Sponge modes avoid this by segmenting the sponge state into key and I/O, but
your construction is not segmented.  STROBE also puts in a tag on calls to the PRF
which says what the output will be used for (encryption, decryption, MAC tag, key
derivation, session hash, etc).  BLINKER does too, but I vaguely remember some
sort of issue in that, like maybe it puts in that tag in the next block after consuming the
output in some cases.

Cheers,
— Mike


> On Jun 26, 2015, at 9:21 PM, Trevor Perrin <trevp at trevp.net> wrote:
> 
> 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
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise