[noise] Notes and nits

[Trevor Perrin]

Thanks Jason,

Good feedback, I've updated the spec with clarifications and rationale:

https://github.com/trevp/noise/blob/master/noise.md

Comments:


On Fri, Jun 26, 2015 at 7:03 AM, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
>
> - "64bit nonce"
>
> RFC7359 specifies a 96bit nonce and a 32bit counter for
> ChaCha20/Poly1305 construction. Is there a good reason to deviate from
> this recommendation?

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.


> - "KDF(k, n, input): Takes a cipher key and nonce and some input data
> and returns a new cipher key. The KDF should call GETKEY(k, n) to
> generate an internal key and then provide a PRF when keyed by the
> internal key." ... "KDF(k, n, input): HMAC-SHA2-512(GETKEY(k, n),
> input). The first 32 bytes of output are used as the new k."
>
> This seems new from previous drafts I read. What's the reasoning?
> Where does HKDF not do the trick? In previous revisions I recall you
> doing a similar counter operation to HKDF. Now there's a construction
> involving encryption?

Good question.

Previously Noise tracked the encryption key (aka "cipher context") and
"chaining variable" separately.  New DHs would be combined with
previous CC through a KDF and output a new "CC" and "CV".  The CC
would be used for encrypting, and the CV would be input for later KDF.

I've tried to simplify and replace CC and CV with a single secret
variable 'k', which is a cipher key, and 'n', a nonce.  K and n are
used for encryption, and to absorb a new DH output you do:

k = HMAC-SHA2-256(PRF(k, n), <new_dh>)
n = 0

PRF(k, n) : encrypt a block of zeros and take first 32 bytes.

The rationale for PRF is that the cipher key k shouldn't be fed
directly into a different crypto algorithm.  So we repurpose the
encryption algorithm to get a value derived from k.  The definition of
PRF allows reusing the encryption function, or short-cutting it and
just calling ChaCha20 or AES directly to ignore the MAC.

So 'k' is serving both to accumulate DH and as a cipher key.  I'm
tentatively adding a requirement that k be at least 256 bits and that
KDF be collision-resistant, unless I can convince myself that's not
necessary.


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

Clarified most of your other points.


> - "The prologue data is returned via some callback."
>
> Er, what? Do you mean to say, "the prologue data is processed" or "the
> prologue data is read" or "the prologue data is examined"?
>
> Also - isn't the prologue authenticated? Shouldn't it be noted that it
> should be passed as authtext to the AEAD?

Removed this.  The prologue could be used to divert processing (for
example, signal a new protocol version), but I'll need a more
thought-out discussion of that later.


> - "The following "Handshake" protocols represent handshakes where the
> initiator and responder exchange messages."

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

Trevor