A Repeated Nonce Can Defeat a Strong Encryption Key

A backup restores the application, its encryption key and yesterday’s counter. The service starts normally. Its next encrypted message may now reuse a value that the cipher required to be unique. Nothing on the screen announces the mistake.

This is why a security assessment cannot stop at the words AES-256. The algorithm matters, but so does the state surrounding every encryption operation. A nonce is one of those inputs. For ordinary AES-GCM, using the same nonce again with the same key can undermine confidentiality and authentication. A longer key does not repair that mistake.

The key is only part of the construction

Authenticated encryption takes a key, plaintext and, depending on the interface, a nonce and associated data. It produces ciphertext and an authentication tag. The receiver must verify the tag before treating the recovered bytes as trustworthy. Associated data can bind a document to its context without hiding that context.

A useful mental model is an encrypted document coupled to a record identifier. If the identifier is authenticated, moving the ciphertext under a different identifier should cause verification to fail. If it is merely displayed beside the ciphertext, that protection has not been established. Google’s Tink AEAD documentation explains this distinction and explicitly warns that associated data is not confidential.

The nonce normally does not need to be secret. It needs to meet the rules of the selected construction. An attacker may know every nonce without learning the plaintext. Conversely, keeping a repeated nonce out of view does not restore the missing security property.

Failures appear at operational boundaries

Consider two workers encrypting with a shared key. Each starts its own counter at zero. The counters are individually orderly, but their outputs collide. A similar problem can arise when a virtual machine is cloned or an old snapshot restores a counter while retaining the key. These are illustrative failure scenarios, not findings about a named application.

A durable design must account for concurrency and recovery. It might allocate disjoint nonce spaces, maintain state that cannot roll back with the workload, or use a well-reviewed library that manages appropriate random nonces within documented usage limits. Choosing randomly is not equivalent to proving collisions impossible. The number of operations and the size of the nonce space still matter.

New keys create new scopes for nonce uniqueness. That makes per-file keys relevant to the discussion, but it does not answer every question. A file may be rewritten repeatedly under one key. A multipart upload may encrypt many chunks. Retries must distinguish resending an existing ciphertext from generating a fresh ciphertext with accidentally recycled inputs.

Misuse resistance is a specific property

RFC 8452 specifies AES-GCM-SIV, a construction designed to tolerate accidental nonce reuse more safely than ordinary AES-GCM. Its security analysis still imposes limits. Repeated inputs can reveal equality, and the specification does not turn arbitrary misuse into a safe engineering practice.

This is a useful example of why product comparisons need exact names. AES-GCM and AES-GCM-SIV are not interchangeable labels. Nor does an implementation inherit misuse resistance because a marketing page mentions the second construction. The selected library, mode, parameters and actual call path have to agree.

A migration between constructions needs a versioned ciphertext format. Old records must remain readable without allowing an attacker to force a weaker interpretation. The decoder should reject unknown or inconsistent versions rather than guessing until a decryption attempt succeeds. This is an engineering requirement to assess, not an assertion that one migration recipe fits every system.

What a useful review should demonstrate

Ask for tests covering parallel writers, a restored snapshot and an interrupted write. Check how a key is identified, how nonce allocation survives restart and what happens when allocation fails. A test that encrypts one message successfully proves very little about a year’s operation.

The negative tests matter just as much. Modify the ciphertext, the tag and the associated context separately. Each invalid input should fail closed, without releasing unauthenticated plaintext to the application. Do not run destructive experiments against production records; use an isolated fixture with known test keys.

For the historical UseCrypt Safe discussion, AVLab’s technology article supplies context about encrypted storage and key management. It does not, by itself, establish a current build’s nonce-allocation behaviour. A version-specific implementation review is the appropriate evidence for that question.

The practical purchasing question is precise: can the supplier show that encryption stays correct after recovery, cloning and concurrent use? A cipher name identifies a component. The answer shows whether the deployed system preserves that component’s assumptions.