How encryption works,
and what it protects.

Encrypted does not always mean the same protection.

Consider storing a delivery address. Transport, disk, and data encryption protect different boundaries.

Transport encryption / TLS

Protects communication between browser and server. The receiving server can process the address; TLS does not automatically protect database contents or a compromised application.

Storage encryption

Protects against stolen disks and backup media. If the database transparently decrypts normal reads, users with SQL read access can still see addresses.

Encryption before storage

Encrypt the address in the application and store ciphertext. Separate database read permissions from key-use permissions to protect against database-only theft.

OneNym combines these layers with purpose-specific authorization. Strong cryptography matters, as does limiting decryption paths.

The implementation decrypts the entire address record in memory and projects only permitted fields into the response. It is not field-level encryption. Recipients must manage returned plaintext; customers must also manage logs and storage along the registration path. Getting started

Protect a data key with a separate key.

A DEK encrypts the address; a KEK protects that DEK. This is envelope encryption. An example with a dedicated DEK for each address follows.

1. Generate a DEK using a cryptographically secure random source and encrypt the address with authenticated encryption.
2. Wrap the DEK with a KEK managed by a key management service. Wrapping encrypts and protects the key.
3. Store ciphertext, the wrapped DEK, key version, and decryption metadata. Do not store a plaintext DEK in the database.
4. When an address is needed, authorize the tenant, purpose, record, and fields.
5. The authorized service unwraps the DEK, decrypts the address, and returns only permitted fields.

Database                       Key management service
Encrypted address              KEK protecting the DEK
Wrapped DEK                    Key-use permissions and audit
Nonce / tag / key version
          ↓ Authorized service accesses both
       Temporary decryption → Delivery processing

Even a non-exportable KEK can be abused if its use permissions are stolen. Separate database and KMS access, administration, emergency operations, and service credentials. Protect decrypted memory and key caches too.

Manage KEKs through cloud key services.

The address Vault uses Azure Key Vault to manage its KEK. Separate permission to use the key protecting data encryption keys (DEKs) from database access.

Cloud services control keys and access to cryptographic operations. OneNym first authorizes tenants, records, fields, and purposes. Business apps get limited vault API permissions, not direct KEK access.

Two different kinds of key rotation.

Rotating a KEK can rewrap DEKs without changing data ciphertext. A compromised DEK requires re-encryption with a new DEK. Rotation cannot recover stolen plaintext or copies of old keys and ciphertext.

Detect substitution as well as protect confidentiality.

Authenticated encryption such as AES-GCM detects ciphertext changes through an authentication tag. Reject failures. Never reuse a nonce with the same AES-GCM key, including across retries and multiple servers.

Bind tenant ID, record ID, and schema version as additional authenticated data (AAD). Ciphertext copied from tenant A into tenant B's record fails verification when checked against the expected tenant B context.

AAD is not encrypted; do not put secret addresses in it. Derive expected IDs from authenticated requests and trusted records. Trusting IDs supplied alongside substituted ciphertext does not preserve the boundary.

What remains protected in a breach?

Only a database copy is stolen

Correct encryption protects address contents if plaintext keys and other plaintext copies are absent. Evaluate metadata exposure such as counts, IDs, timestamps, and sizes separately.

Database and decryption permissions are compromised

Encryption alone cannot prevent access. Limit impact with scoped authorization, usage controls, anomaly detection, and revocation.

The delivery server is compromised

Addresses decrypted during legitimate processing may be stolen. Return no fields beyond what delivery requires.

An address has already been sent to a partner

Revoking the vault key does not erase shared plaintext. Manage partner retention and deletion too.

Questions to ask before deployment.

Beyond whether AES is used, ask who can use keys, whether decryption is scoped, whether key use is audited, how quickly revocation reaches caches, and how lost keys are handled. Protection boundaries and operational evidence support evaluation.

Technical references

For general encryption and key management principles, see OWASP's Cryptographic Storage Cheat Sheet; for key hierarchies, see Microsoft's encryption-at-rest guidance. This page explains OneNym's protection design; per-record keys are an illustrative configuration.