Built-in noncing strategies

[tel]

One of the biggest weaknesses of using NaCl is that nonces must all be unique and it's up to the end user to ensure that. newNonce is sufficient for all of default NaCl, but it requires IO. IsNonce can help in pure settings, but you have to remember to always call nudge. If there was a Noncey monad it'd be easy enough to statically ensure this behavior locally. There are times that two communicating parties would want to collaborate on nonce incrementing, though, so those strategies would have to be possible: Endo Nonce?

[linearray]

Just some incoherent ideas off the top of my head, so I don't forget about it:

I see two main Noncing Strategies (in Box, because that's what I mainly use):

• Random nonces. Gets the job done regarding confidentiality, but leaves you open to replay attacks (unless some other precautions are taken).
• Incrementing nonces. Protects against replays, but harder to make sure they are never used twice with the same key.

The dual to this are persistent keys and session keys. With persistent keys you probably will always want random nonces, because it's so much easier to guarantee uniqueness. With session keys incrementing or otherwise predictable nonces are (usually?) better, because you can detect replays.

We could have two types of keys and use them to parameterise a monad that takes care of supplying the nonces, one for the Random, one for the Incrementing case.

In the latter case we could also check that decrypted packets have consecutive nonces.