Understand shared-key encryption

Symmetric encryption uses the same secret key to protect and recover data. AES is the standard algorithm, and a 256-bit key is the common choice:

openssl rand -hex 32
# 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

It is fast, hardware-accelerated on modern CPUs, and works well for stored data and large messages. When one system encrypts data for itself — database fields, backups, files at rest — symmetric encryption is the right tool.

The key is the whole problem

The algorithm is the easy part. Here is the hard part: anyone with the key can decrypt, and usually create valid ciphertext too. Symmetric encryption cannot distinguish between the parties that share a key.

That turns key distribution into the central design question. Every copy of the key is a place your data can leak from. Before shipping, answer three questions:

who can read the key?    (developers, CI, every replica, backups?)
where does it live?      (env var, file, secret store, KMS?)
how does it get there?   (deploy pipeline, manual paste, service call?)

If every application instance needs the key, each one becomes part of the threat model. A concrete failure: every application replica receives the same master key in an environment variable. One compromised debug endpoint can expose the key and every record protected by it. The encryption was fine. The distribution made it worthless.

Reduce the blast radius

Keep the key separate from the data it protects where possible. A key sitting in the same database as the ciphertext protects against nothing.

Central key storage — a KMS or a vault — can narrow access and record every operation, but each service allowed to decrypt remains trusted. You have not removed trust, you have concentrated and logged it.

Separate keys by environment, tenant, or purpose when the blast-radius reduction justifies the operational cost. A leaked staging key that cannot touch production data is an incident. A single key shared everywhere is a catastrophe.

My advice: design the key’s life first — generation, storage, access, rotation — and only then write the encrypt call. The next lessons cover the encrypt call itself.

Practice

Create a key-access map for one encrypted field, including developers, CI, application replicas, backups, and recovery jobs. Save the effective permissions for each identity. Then revoke one test replica and prove it can no longer decrypt while another authorized replica still can.