ADR-006 Envelope encryption

Context

Vault instructions are restricted even though they are not passwords. A database backup, a replica, or a broad admin query must not yield readable guidance. Titip will start as a modular monolith with one database; encryption has to carry the confidentiality boundary that network isolation will not.

Decision

Restricted content is encrypted in the application before it is written:

plaintext
  → data encryption key
  → encrypted content

data encryption key
  → KMS key
  → encrypted data key, stored beside the ciphertext

The database must not store restricted plaintext. Keys must not be stored in the repository, in client bundles, or in audit events.

Prototype infrastructure may use a local or development KMS. The call shape stays the same so production KMS is a configuration change, not a schema change.

Field-level encryption applies at least to instruction body and document bytes. Vault title and recipient display name may remain confidential metadata so the owner can see a list without decrypting every body. That metadata is still not public.

Deletion of a vault must delete the encrypted data key. Ciphertext without its key is not a substitute for deletion in the product promise, but key destruction is mandatory in addition to row deletion, because backups exist.

Consequences

• Search over instruction bodies is not a prototype feature. Do not add a plaintext shadow column to enable it.
• The vault module owns encryption. Other modules store ids.
• Loss of KMS access is a availability incident, not a reason to fall back to plaintext.

Related

TITIP-005, architecture/data-classification.md