AEAD design review: ciphertext still needs an identity and context

In the AEAD design review I focused on a failure mode that encryption alone does not prevent: moving otherwise valid ciphertext into the wrong tenant or record context. A tag can authenticate bytes while still leaving an application-level identity boundary unclear.

Authenticated encryption with associated data (AEAD) is a useful building block for that problem.

Google Tink's AEAD guidance explains that associated data is authenticated alongside the ciphertext, but not encrypted. It can include a tenant identifier, resource identifier, schema version or purpose label. Decryption succeeds only when the associated data supplied at that point matches what was used during encryption.

Here is a contract sketch, not an implementation of AES-GCM:

encrypt(
  plaintext = record,
  associatedData = canonical(tenantId, recordId, schemaVersion)
)
→ keyIdentifier + nonce + ciphertext + authenticationTag

decrypt(
  ciphertext,
  associatedData = canonical(requestTenantId, requestedRecordId, schemaVersion)
)
→ plaintext OR authentication failure

The canonical encoding must be versioned. Concatenating arbitrary strings without separators can be ambiguous; silently changing a schema or identifier encoding can make historical records undecryptable.

1. Nonce reuse with AES-GCM. Nonce uniqueness under one key is critical; rely on a well-maintained encryption library instead of custom IV handling.
2. Treating associated data as secret. Tenant IDs and metadata remain visible. Use it for binding, not confidentiality.
3. Equating successful decryption with authorization. A caller must still be authenticated and permitted to read the record. AEAD detects context tampering; it doesn't enforce your business roles.

Key rotation introduces another state transition: a record needs the identifier of the key that can decrypt it, and a migration policy must preserve compatibility without allowing unsafe downgrades.

Use a vetted AEAD library in a test environment. Encrypt a fixture for tenant A, then attempt decryption under tenant B or a different record ID. Both should fail. Verify legitimate decryption, key-ID handling and tampering behavior separately. Do not paste production key material into a browser demo.

• Google Tink: choosing AEAD encryption
• OWASP: key management guidance

Scope: My architecture and threat-boundary review. The article analyzes the failure mode; it does not claim a live key-service measurement or a customer system audit.