Confidentiality and integrity together
Authenticated encryption with associated data encrypts plaintext and produces an authentication tag. Verification detects unauthorized changes to the ciphertext and to associated data that remains visible. The receiver must verify the tag before it releases or acts on plaintext.
Associated data can bind a record to its version, tenant, object identifier, content type, purpose, or other context that must not change but does not need encryption.
Construction and record format
Use a standard AEAD algorithm through a maintained high-level library. Store an explicit format version, algorithm or suite identifier where migration needs it, key identifier, nonce, associated-data definition, ciphertext, and tag. Define exact serialization and size limits.
Do not compose encryption and authentication from raw primitives without a reviewed protocol. Do not use unauthenticated encryption modes for application data. Reject a failed tag with no plaintext side effect and one stable outward error.
Nonce and key discipline
Every AEAD construction defines nonce requirements. For GCM, reuse of a nonce with the same key can destroy confidentiality and authentication. Use a construction and library that makes correct nonce generation practical. Coordinate nonce state across processes, replicas, rollback, backup restore, and retry.
Use a dedicated key for one purpose and algorithm. Bind associated data identically on encryption and decryption. Rotate keys and formats through a versioned read-old, write-new process with measured completion.
Failure and residual risk
AEAD protects bytes, not the truth or authorization of their content. It exposes message length and associated data. A compromised endpoint can read plaintext and invoke the key. Nonce reuse can be catastrophic and may not create an obvious error. Backups and rollback can restore old nonce counters or retired keys. Error and timing behavior can expose a decryption oracle.
Pomerium boundary
Pomerium uses authenticated transport protocols to protect traffic on configured connections. Application-level stored data needs its own protection when the storage, backup, operator, or tenant threat model requires it. Pomerium does not select the application's AEAD record format, keys, nonces, associated data, or migration.
Evaluation checklist
- Does the design need confidentiality and integrity, and does it use a standard AEAD library?
- What visible associated data must be bound to the ciphertext?
- How is nonce uniqueness or unpredictability guaranteed across replicas, retry, restore, and rollback?
- Is the record format versioned for key and algorithm migration?
- Is plaintext withheld until authentication succeeds with no partial side effect?
- Where can an authorized endpoint or compromised runtime still read plaintext or invoke the key?
