You will almost never implement a cryptographic primitive. You will constantly choose between them, and the choices have exactly one correct answer each. This chapter is those answers, plus enough of the reasoning that you can defend them in a design review.

SHA-256 is an excellent hash function and a terrible password hash, and the reason is that it is fast. Speed is a virtue for integrity checking and a catastrophe for password storage, because an attacker with a leaked database is running the same function billions of times per second on commodity hardware.

• Use argon2id where available. It is memory-hard, so an attacker cannot get large speedups from GPUs or custom hardware. Tune the memory and time parameters so a single verification takes a few hundred milliseconds on your production hardware, and re-tune annually.
• bcrypt is still acceptable and widely deployed. Note its 72-byte input limit, which silently truncates long passphrases — pre-hash if you allow them.
• Salt is per-password and not secret. It defeats precomputed tables. Modern libraries handle it inside the hash string; if you are managing salts yourself, you are at the wrong level of abstraction.
• A pepper is different — a secret held outside the database, mixed in before hashing. It means a database leak alone is insufficient, which is a real and cheap improvement, but only if the pepper genuinely lives somewhere else, such as a KMS.
• Compare in constant time, and never log a password or include one in an error message. Both happen, routinely, through generic request logging.

Encryption without authentication lets an attacker modify the ciphertext, and the ways that goes wrong are not obvious. The padding oracle attack recovers plaintext entirely without the key, using nothing but the difference between a padding error and a decryption error — which is why AES-CBC without a MAC has broken so many real systems.

Use AEAD — authenticated encryption with associated data. AES-GCM or ChaCha20-Poly1305. These encrypt and authenticate in one operation and fail closed.

• Envelope encryption is the pattern to know. A data key encrypts the data; a master key in a KMS (key management service) or HSM (hardware security module) encrypts the data key; the encrypted data key is stored beside the ciphertext. Rotating the master key then means re-encrypting only the small data keys, not petabytes of data. Every cloud KMS implements this and it is worth being able to explain.
• A key has a lifecycle: generate, distribute, rotate, revoke, destroy. Most organisations implement the first and none of the rest, which is why key rotation is a project rather than an operation.
• Rotation limits blast radius; it does not fix a compromise. If a key leaked six months ago, rotating today protects future data and not past data. Say that plainly — rotation is frequently proposed as if it were remediation.
• Separate keys by blast radius: per tenant, per environment, per data classification. One key for everything means one compromise for everything.
• Never commit a key. And when one is committed, rotating it is mandatory — removing the commit is not sufficient, because git history is distributed and the value is already in every clone and almost certainly in a scanning bot's database within minutes.

Standardised post-quantum algorithms exist — ML-KEM for key encapsulation, ML-DSA and SLH-DSA for signatures — and hybrid key exchange combining a classical and a post-quantum algorithm is already deployed in TLS by major browsers and CDNs.

The practically important idea is harvest now, decrypt later: an adversary can record encrypted traffic today and decrypt it when capable hardware exists. That makes the urgency proportional to how long your data must stay confidential. For a session cookie, it does not matter. For state secrets, medical records or long-lived intellectual property, it already does. That framing — urgency scaled to confidentiality lifetime rather than to a predicted date — is the mature answer.

The other thing worth saying is that crypto-agility is the real deliverable: being able to change algorithm without re-architecting. Most systems cannot, because the algorithm is assumed in a hundred places, and that inflexibility is the thing to fix now.