You have data that should not sit in plaintext in your database. API keys, customer PII, notes that end users wrote and expect to stay private. AES is the tool for that job: a symmetric block cipher trusted by governments and banks. One key encrypts; the same key decrypts. The tool here does AES-256 in two modes: GCM (the modern default, with built-in integrity) and CBC (the legacy choice, only use it when the other side demands it).
GCM versus CBC comes down to one question: do you need to detect tampering or just hide the content?
AES-CBC on its own only hides content. Flipping a bit in the ciphertext corrupts the corresponding plaintext block in a predictable way. An attacker who controls the ciphertext controls the decryption. The classical fix -- HMAC-then-Encrypt -- is subtle to implement and easy to get wrong (see: BEAST, Lucky13, Vaudenaya libraries shipped these bugs). AES-GCM solves this natively: if a single bit of the ciphertext is tampered, decryption fails instead of returning corrupted data.
Pick GCM unless you have a specific reason not to.
GCM has one hard rule about nonces (the Initialization Vector by another name): never reuse a nonce with the same key. If you encrypt two different plaintexts with identical (key, nonce), an attacker can XOR the two ciphertexts, recover the XOR of the two plaintexts, and drill down from there. The tool generates a fresh random 96-bit nonce on every call -- do not override this.
Output format from this tool looks like:
salt (32 bytes hex) | nonce (24 bytes hex) | ciphertext+tag (base64)
Semitolonated for easy splitting. For a correct toolchain:
- Salt + PBKDF2 derive a key from the password (100,000 iterations is the default, raise it as hardware speeds up).
- Nonce is random per encryption.
- A -- GCM only -- ath data (the request path, the user ID, the "context" of the message) without encrypting it.
Raw-key mode is here too: feed in a 32-byte (256-bit) hex string and use it directly. Useful for server-side scenarios where a KMS already gave you a key. Do not feed UTF-8 passwords straight into AES -- always run a KDF first. PBKDF2, scrypt, and Argon2 exist precisely so that entropy-poor human passwords do not immediately fall to brute force.
AES key sizes in context:
- AES-128: 128-bit key, 10 rounds. Secure, fast, sufficient for almost everything. Approved through SECRET classification by NIST.
- AES-256: 256-bit key, 14 rounds. ~40% slower than AES-128. Required for TOP SECRET classification and by various compliance regimes. Only choose this if you have a compliance reason, or if you plan to store ciphertext for decades (Grover's algorithm).
What happens if you lose the password? The data stays encrypted forever. This is by design. The only recovery path is "guess the password and verify the GCM tag." Losing a 256-bit random key means the ciphertext is mathematically unrecoverable. Back up your keys.