[noise] Notes and nits

[Jason A. Donenfeld]

Hi Trevor,

I have a bunch of comments and nits and places where I was confused
with the spec. I was hoping you could clarify some things. Apologies
ahead of time if any comments here are due to simple ignorance. Lots
of feedback follows below.

I'll probably be implementing this in kernelspace at somepoint, to
replace the key exchange I described in previous messages to this
list.

Regards,
Jason


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


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

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.

Nitpick - you mention "PRF" here, which isn't introduced prior at all.


- "While processing a message, the processor will maintain a local
pointer to the last byte written (or read), and will write (or read)
after that, and advance the pointer."

I'm not sure I see the relevence of this statement.

u8 msg[size];
u8 *ptr = msg;
readbyte(ptr++);
readbyte(ptr++);
readbyte(ptr++);
readbyte(ptr++);

Okay, but why specify this design detail?


- ""Clear" reads and writes are performed without encryption.
"Encrypted" reads and writes will encrypt or decrypt the value using k
and n if k is non-empty."

"if k is non-empty", and otherwise falls back to "Clear", presumably?
Might want to explicitly note this.


- "dhss, dhee, dhse, dhes: A DH calculation is performed between the
creator's static or ephemeral key (specified by the first character)
and the consumer's static or ephemeral key (specified by the second
character). The output is used to update k by calculating k = KDF(k,
n, output)."

Just to clarify -- the output of this calculation is *not* written to
the message, right? It's only used to update "k"?


- "Takes an ASCII label and writes its bytes into h sequentially,
zero-filling any unused bytes. The label should be unique to the
particular ciphertext, descriptor, and protocol."

Could you give an example? Would random ascii bytes work? Or does it
need to be static ahead of time, and something shared and known by
both parties? Like "noise-255-chacha-dancing-vpn-protocol"? But then -
unique to the particular ciphertext? What? No two ciphertexts should
be the same ideally, so I'm not sure I understand.


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


- "this should be used for counter-based nonces instead of random nonces. "

Is it reasonable, then, to just say that after every AEAD operation on
a given session, execute "++session->nonce"?


- " you can alternate setting a nonce with session derivation"

??


- "Typically session derivation will be called twice after a handshake
protocol to provide separate sending and receiving sessions for each
party (the initiator using the first session)."

Do you mean:

parent
  -> session 1
     -> session 2

or

        parent
       /      \
session 1   session 2


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

Could you specify for each of these protocols which ones are
vulnerable to KCI and which ones are vulnerable to replay attack?



- "4) If the descriptor was not empty, h is set to HASH(h || message)."

Where is this `h` ever used elsewhere?