[noise] Implementation question

Alex alex at centromere.net
Sat Apr 16 11:06:36 PDT 2016

It's not clear to me what a clean API for a Noise library should look
like just given the protocol document. As written, the ReadMessage and
WriteMessage functions are members of the HandshakeState object which
should be destroyed after the handshake is over. Indeed, the two
functions seem to have no functionality anyway after the handshake is
complete because, "If there are no more message patterns returns two
new CipherState objects by calling Split()."

What do you do with CipherStates after the handshake is complete?
Sure, you could call EncryptWithAd and DecryptWithAd, but this feels
"leaky" to me -- i.e. that some of the implementation details are
leaking back to the user. If your solution is to have the
Read/WriteMessage functions accept more messages after the handshake is
complete, then they deviate from what the protocol document specifies.

A (maybe) cleaner API choice would be a single "NoiseState" which would
encompass a (possibly null) HandshakeState and a pair of (possibly
null) CipherStates. Read/WriteMessage would /not/ be members of
HandshakeState, and would instead be members of NoiseState. When
called, they would keep track of whether the handshake is complete. If
it is complete, call En/DecryptWithAd. If it's not complete, process
the message tokens.

With this API, the user of the library would simply call
Read/WriteMessage repeatedly for the entire duration of the
conversation. A helper function like, "isHandshakeComplete()" could be
called to ensure that sensitive data isn't given to WriteMessage until
after the handshake is complete.


More information about the Noise mailing list