Open tel opened 11 years ago
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):
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.
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 requiresIO
.IsNonce
can help in pure settings, but you have to remember to always callnudge
. If there was aNoncey
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
?