AES-GCM is the usual first choice for encrypting data, but it has one rule you must not break: never reuse an IV with the same key. Let a well-tested library generate IVs, and cap how many encryptions one key performs. OWASP suggests at most 2^32 with random 96-bit IVs.
Why GCM is the default choice
OWASP's cryptographic storage guidance says authenticated modes should be the first preference, naming GCM and CCM. Authenticated encryption detects tampering as well as hiding content. ECB is to be avoided. For AES, use at least 128-bit keys, ideally 256.
NIST SP 800-38D is the specification: it describes GCM as an algorithm for authenticated encryption with associated data.
The IV rule
OWASP says IV generation should be handled automatically by the library, and that key rotation must enforce IV uniqueness across all instances sharing a key. For input length limits and IV construction, it points to NIST SP 800-38D rather than restating them.
This is why home-grown code is risky: a counter that resets after a restart, or two servers sharing a key with separate counters, can repeat an IV without any error message.
The usage cap
OWASP's key management guidance says that for AES-GCM with random 96-bit IVs, each key should perform at most 2^32 encryption operations across all devices that share it. That is about 4.3 billion. A service encrypting every API payload under one key could reach it.
Rotate on volume, not only on calendar. See how often to rotate encryption keys.
Practical checklist
- Use a high level library or key service API instead of raw primitives.
- Do not write your own IV counter or reuse a constant IV.
- Prefer per-object data keys in envelope encryption, so each key encrypts few messages. See envelope encryption explained.
- Count operations per key where you can, and alert before the cap.
- Bind context (record ID, tenant) as associated data so ciphertext cannot be moved between records.
- Test decryption of tampered data and make sure it fails.
Where teams slip
The failures OWASP's guidance points at are mostly about shared state. A key shared by several instances needs IV uniqueness across all of them, not per instance. Restores from snapshot can rewind a counter. Copying a configuration with a hard-coded key and IV into a second service doubles the exposure silently. Nothing crashes when this happens, which is why it survives code review. The fixes are dull and effective: one library call that picks the IV, per-object data keys so no key is busy, and a metric of encryptions per key that someone watches. If you inherit older code that builds its own IVs, schedule a review and plan a migration to a library managed approach.
Quick check
Does a random IV fix the problem?
It helps, but random 96-bit IVs make collisions more likely as volume grows, which is why a usage cap applies.
Is the IV secret?
No. It is usually stored with the ciphertext. It only needs to be unique per key.
Sources
Last reviewed: 19 October 2026.
