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

[Justin Cormack]

The spec is not necessarily directly an API specification, it is a
specification of the protocol, so
you are not required to expose it exactly as an API.

I do think that the spec could maybe say that you either provide
EncryptWithAd() or
EncryptWithAdAndNonce() but not both at the same time, and remove SetNonce.
That would remove opportunities to mix them. Implementations that set nonces are
probably much less generic. It seems a nicer interface than set,
making it explicit if
you are setting nonces that you always need to.

Justin


On 2 August 2018 at 19:06, jake mcginty <me at jake.su> 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®:
>
>     session.set_receiving_nonce(nonce)
>     session.read_message(...)
>
> will instead become:
>
>     session.read_message_with_nonce(nonce, ...)
>
> and the user will be required upon finishing the handshake to choose a transport mode with either explicit or implicit nonces to prevent some footgunning: session.into_transport_mode() or session.into_stateless_transport_mode().
>
> I'd obviously like to keep from unnecessarily diverging from spec API, so I thought this would be a good opportunity to float this type of change for the main noise spec as well. Something like:
>
> * Remove SetNonce(nonce) from CipherState
> * Add {Encrypt,Decrypt}WithAdAndNonce(nonce, ad, plaintext) (but that's a very long-winded method name)
>
> Thoughts?
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise