The vast majority of encryption algorithms must be used in a nonce-respecting scenario. This is part of the contract to achieve the claimed security properties.
Alternatives require multiple passes over the data, which is not applicable to some protocols in addition to having performance implications.
Common protocols such as TLS transparently handle nonces in a safe way. But the primitives used in TLS may require additional steps to be safely used is other contexts, especially in distributed systems.
Whenever applications try to use these primitives directly, using a fixed key and picking nonces at random is a very common practice. Unfortunately, due to their small size, nonces collisions can quickly happen.
We're missing standard constructions with large nonces that would alleviate this problem, because IETF protocols haven't needed them. But there's a lot of evidence that many custom applications and protocols do.
There are multiple great proposals to derive AES-GCM subkeys and nonces from a key and a large nonce. We may expect convergence and adoption in crypto libraries soon.
Until then, constructions such as XSalsa20 and XChaCha20 are widely implemented and deployed. If you don't need NIST compliance, they're excellent choices.
But my recommendation today would be to replace AES-GCM with the AEGIS family of algorithms whenever possible. They have nice properties that AES-GCM doesn't have, including more comfortable usage limits, much better performance and large nonces up to 256 bits.
This page [1] and that draft [2] summarize usage limits of common constructions, including when using random nonces.
The vast majority of encryption algorithms must be used in a nonce-respecting scenario. This is part of the contract to achieve the claimed security properties.
Alternatives require multiple passes over the data, which is not applicable to some protocols in addition to having performance implications.
Common protocols such as TLS transparently handle nonces in a safe way. But the primitives used in TLS may require additional steps to be safely used is other contexts, especially in distributed systems.
Whenever applications try to use these primitives directly, using a fixed key and picking nonces at random is a very common practice. Unfortunately, due to their small size, nonces collisions can quickly happen.
We're missing standard constructions with large nonces that would alleviate this problem, because IETF protocols haven't needed them. But there's a lot of evidence that many custom applications and protocols do.
There are multiple great proposals to derive AES-GCM subkeys and nonces from a key and a large nonce. We may expect convergence and adoption in crypto libraries soon.
Until then, constructions such as XSalsa20 and XChaCha20 are widely implemented and deployed. If you don't need NIST compliance, they're excellent choices.
But my recommendation today would be to replace AES-GCM with the AEGIS family of algorithms whenever possible. They have nice properties that AES-GCM doesn't have, including more comfortable usage limits, much better performance and large nonces up to 256 bits.
This page [1] and that draft [2] summarize usage limits of common constructions, including when using random nonces.
[2] https://doc.libsodium.org/secret-key_cryptography/aead
[3] https://datatracker.ietf.org/doc/draft-irtf-cfrg-aead-limits...