Document in Authenticated Encryption

[alexanderzjs]

Just quote from the gitbook: "Messages encrypted are assumed to be independent. If multiple messages are sent using this API and random nonces, there will be no way to detect if a message has been received twice, or if messages have been reordered. If this is a requirement, see the encrypting a sequence of a set of related messages section."

Ideally, random nonces could ensure nonce uniqueness. However, there would be chances that two random nonces are the same. At least in NIST standards, they claim the chances should be lower than 2^{-32}. Due to birthday attack, the number of messages to be encrypted should be limited, especially for GCM and CTR mode with limited nonce size. Reference can be found here: https://soatok.blog/2020/12/24/cryptographic-wear-out-for-symmetric-encryption/ or NIST standards for these different modes. It may be better to point this out in order to avoid bugs. Best way may be rekey after certain limit.

[samuel-lucas6]

There's a separate repo for the documentation. That page also mentions the following:

Ciphers such as AES do not feature nonces large enough to be randomly chosen without taking the risk of repeating a nonce.

More accurately, a single nonce shouldn’t be used to encrypt different messages with the same key. Using the same nonce to encrypt different messages with different keys is perfectly safe.

Therefore, ciphers with short nonces can be safely used, but require keys to be frequently rotated, in addition to generating a new key for every stream. This requires support from application-level protocols, and can be tricky to implement.

[jedisct1]

That page also includes guidelines for usage limits and how to safely use nonces for each construction.

All high-level APIs in libsodium use 192-bit nonces and don't have such limitations.

[alexanderzjs]

Good to know the limitations and potential solutions are brought onto the table, so that developers will not fall into the hole of implementing buggy code :-)

[jedisct1]

There's also a section on nonce extension.

Unlike XSalsa20 (used by crypto_box_* and crypto_secretbox_*) and XChaCha20, ciphers such as AES-GCM and ChaCha20 require a nonce too short to be chosen randomly (64 or 96 bits). With 96-bit random nonces, 2^32 encryptions is the limit before the probability of duplicate nonces becomes too high.

Specifically for AES-GCM, there's now a more efficient way to use large nonces, which is likely to become part of libsodium once the specification is stabilized.