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

[Trevor Perrin]

Jake wrote:
> The upcoming release of Snow is planning to drop the SetNonce-style API because, in my opinion, it feels too enabling for people practicing Unsafe Noncing®:

When we put "out-of-order transport messages" into the spec I think
the goal was just to acknowledge that out-of-order decryption, and
things like WireGuard, were legitimate.  So we didn't think much about
safety / ergonomics of the API, and SetNonce was just the easiest
thing to hack into the spec.

We could certainly replace SetNonce with EncryptWithAdAndNonce /
DecryptWithAdAndNonce.

But at that point, having the CipherState object store an (unused)
nonce becomes awkward, and I think Luke's point is that we'd be better
off with an API that moves the nonce responsibility entirely to the
caller:


On Fri, Aug 3, 2018 at 10:29 AM, Luke Mather <luke.mather at cerb-labs.com> wrote:
>
> That said, there are some alignment issues if such a higher-level
> protocol wanted to directly develop against the explicit method
> signatures as defined in the core spec right now. Maybe something like a
> separate `DatagramCipherState` (or better named!) interface to use, as
> well as the subsequent modifications to the SymmetricState and
> HandshakeState interfaces you'd have to make to pass through nonce values.


So we could have a "DatagramCipherState" object (or "RawCipherState"?
"AEADState"?) that holds a key without a nonce.

Then we could move nonce handling into the higher-level objects.  Or
we could keep a CipherState but have it store an AEADState alongside a
nonce and do default nonce handling.  Then in the "Out-of-order"
discussion, we could mention that applications are allowed to discard
the CipherState and access the underlying AEADState.

I think I'd lean towards keeping the CipherState API as-is to minimize
changes and because it's convenient to deal with a CipherState for
both handshake and transport phases, but just add a lower-level
object?

Trevor