laysakura
commented
3 years ago @alcore Thank you.
I thought XChaCha20 nonce is large enough so that;
the probability can be astronomically low
but
The point is to guarantee that a reused nonce will never be observed.
is quite true and very important point.
I already created issue about incremental nonce feature but close it since this report is more informative.
I will do the following. What do you think?
- [ ] Adds new API to use incremental nonce (state control is sender/receiver's responsibility)
- [ ] Documents about danger of random nonce (like @alcore writes here)
Via https://github.com/laysakura/serde-encrypt/blob/9ba98fa857464e2e75c017407c0a1345d697b896/src/traits/serde_encrypt_public_key.rs#L60
While the probability can be astronomically low given a large enough nonce, the probability that a nonce will be reused still exists when it is random. Reusing a nonce under ciphers like ChaCha20-Poly1305 or AES-GCM effectively means revealing the encryption secret to an attacker that can observe both of the messages encrypted with the same nonce.
It's for that reason that protocols like TLS use sequential nonces and require implementations to change secrets when the sequence is about to overflow. The point is to guarantee that a reused nonce will never be observed.
Due to the nature of this library and lack of control over how and how many objects get serialized-and-encrypted, nor how they are transported or stored, it effectively means that this library is currently not secure.
I wanted to raise this issue to raise awareness - but do not see an easy fix given the current API, considering maintaining a sequence requires maintaining additional state on a per-key basis and defeats the convenience-centric aim of this library.