Understand shared-key encryption

Symmetric encryption uses one secret key both to protect data and to get it back. AES is the standard algorithm, and a 256-bit key is the common choice. You can generate one from the terminal:

openssl rand -hex 32
# 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

AES is fast, and modern CPUs accelerate it in hardware. It works well for stored data and large messages. When one system encrypts data for itself, like database fields, backups, or files at rest, symmetric encryption is the right tool.

The key is the whole problem

The algorithm is the easy part. The hard part is that anyone with the key can decrypt, and usually produce valid ciphertext too. Symmetric encryption cannot tell apart the parties that share a key.

That makes key distribution the central design question. Every copy of the key is a place your data can leak from. Before you ship, 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, every instance is part of the threat model. Say all your replicas get the same master key in an environment variable. One debug endpoint left open on one replica exposes the key, and with it every record protected by that key. The encryption was fine. The distribution made it worthless.

Reduce the blast radius

Keep the key away from the data it protects. A key sitting in the same database as the ciphertext protects against nothing, because whoever dumps the database gets both.

Central key storage, a KMS or a vault, narrows who can reach the key and records every operation. But every service allowed to decrypt is still trusted. You did not remove trust. You concentrated it and started logging it, which is a real improvement, but not a magic one.

Separate keys by environment, tenant, or purpose when the smaller blast radius is worth the extra operations work. A leaked staging key that cannot touch production data is an incident. One key shared everywhere is a catastrophe.

My advice is to design the key’s life first: how it is generated, where it is stored, who can access it, how it gets rotated. Only then write the encrypt call. The next lessons cover that call.

Try this on your own project: build a key-access map for one encrypted field. List developers, CI, application replicas, backups, and recovery jobs, and write down what each identity can actually do with the key. Then revoke one test replica and confirm it can no longer decrypt while another authorized replica still can.