[noise] Practical safety of the spec's SetNonce API

[Trevor Perrin]

On Mon, Aug 6, 2018 at 4:55 PM, Luke Mather <luke.mather at cerb-labs.com> wrote:
>
> W.r.t 2: Ultimately the majority of the work you'd need to do to safely
> layer Noise over a lossy transport is going to be specific to the
> application, so I don't think the spec should try to do anything other
> than the bare minimum of not getting in the way.
>
> The separation of responsibilities of nonce and key management between a
> CipherState sans setNonce() and a lower-level AEADState does feel cosily
> clean.  A Noise 'cipher function' is quite close to an AEADState already
> --- I haven't checked, but I imagine most Noise libraries will have
> effectively created stateful cipher contexts with InitializeKey()-esque
> methods to handle things like key scheduling, for instance.
>
> We could try to formalise that, move CipherState#InitializeKey() etc
> over to it, see if reducing CipherState to nonce management only doesn't
> have any unexpected consequences, and say users can override or replace
> its functionality under the existing nonce constraints.  It's a bit
> cleaner, as setNonce() is effectively fighting against the existing
> post-incrementing of nonces -- but the benefit is I think pretty small
> given the extent of the changes.

Hi Luke,

That seems like a good analysis and plan of action: we could try
drafting that up, and once we see the text, and spec impact, we can
decide if this approach works or needs any adjustment.

So that's my vote, at the moment...

Trevor