Repository navigation
aead: marker trait + simpler encryption API for randomized nonces #1666
Description
We currently require an explicit nonce for all encryption APIs, including ones which automatically encode the nonce as part of the AEAD message.
For some AEADs we can use purely randomized nonces safely: AES-GCM-SIV, the XChaCha* variants, and the new XAES-256-GCM are all examples of AEAD algorithms which are safe to use with nonces derived from a CSPRNG.
For these constructions, it would be nice if we had APIs that completely delegate nonce generation to a CSPRNG so we could more easily avoid nonce reuse.
Activity
tarcieri commentedon Nov 20, 2024
As discussed in #1713, the encryption API can also wrap up prepending the random nonce to the message, as is customary.
newpavlov commentedon Nov 20, 2024
Are there any protocols used in practice which append nonces to ciphertext?
We potentially could add an
inouttype with reserved header of fixed size. It also could be useful for a more efficient set of prefix encrypt/decrypt methods.aead: add explicit nonce API
tarcieri commentedon May 13, 2026
I'm not aware of any. It seems generally disadvantageous because the nonce is needed before the tag, so putting it at the end is the reverse order you actually need it in (although we don't provide any APIs that would let you perform computation with the nonce without the tag)
newpavlov commentedon May 19, 2026
I guess it matters in the case of online application of an AEAD mode (which we currently do not expose). When you have the whole ciphertext it should be trivial to slice postfix nonce/tag.