Applied cryptography for engineers who use it rather than invent it — the four guarantees (confidentiality, integrity, authenticity, non-repudiation), symmetric encryption and AEAD, hashing/MACs/password storage, public-key crypto and key exchange, signatures and PKI, TLS, key management, and the misuse pitfalls (randomness, timing, nonce reuse) that silently break sound primitives.
Most engineers reach for cryptography wanting "make this secure," but crypto doesn't provide "secure" — it provides four specific, separable guarantees, and using the wrong one (encrypting when you needed to authenticate, hashing when you needed to encrypt) is how most real-world crypto failures happen. This series is about using cryptography correctly as an engineer who builds on top of it, not about inventing it.
Most engineers reach for cryptography wanting 'make this secure' — but crypto doesn't provide 'secure.' It provides four specific, separable guarantees: confidentiality, integrity, authenticity, and non-repudiation. Using the wrong one is how most real-world crypto failures happen.
Symmetric encryption is the workhorse of confidentiality — the same fast primitive protecting your disk, your database fields, and every byte inside a TLS connection. But "encrypt this" is a trap: raw encryption alone doesn't stop tampering, block ciphers need a mode of operation, and modes need nonces that must never repeat. The single right answer for almost every case is authenticated encryption, and this post explains why.
Symmetric encryption is the workhorse of confidentiality — but 'encrypt this' is a trap. Raw encryption doesn't stop tampering, block ciphers need a mode, and nonces must never repeat. The right answer for almost every case is authenticated encryption (AEAD), and this post explains why.
"Just hash the password" is advice that's simultaneously right and dangerous — right that you never store plaintext, dangerous because a fast cryptographic hash like SHA-256 is exactly the wrong tool for passwords. Hashing, message authentication, and password storage are three different jobs that all involve hashing, and confusing them is a classic source of real breaches.
'Just hash the password' is simultaneously right and dangerous — right that you never store plaintext, dangerous because a fast hash like SHA-256 is the wrong tool for passwords. Hashing, MACs, and password storage are three different jobs that all involve hashing.
Symmetric encryption has a chicken-and-egg problem: to share a secret key securely, you seem to need a secure channel — which is what you were trying to build. Public-key cryptography is the astonishing idea that broke that loop: two mathematically-linked keys where knowing the public one doesn't reveal the private one. It's the foundation of key exchange, digital signatures, and essentially all secure communication over the open internet.
Symmetric encryption has a chicken-and-egg problem: sharing a secret key securely seems to need a secure channel. Public-key cryptography broke that loop — two mathematically-linked keys where the public one doesn't reveal the private. It's the foundation of key exchange and signatures.
A public key lets anyone encrypt to you and verify your signatures — but it raises a new question: how do you know a public key really belongs to who it claims? If an attacker can substitute their own public key for the bank's, all the cryptography in the world protects your connection to the attacker. Solving "whose key is this?" is what certificates, certificate authorities, and chains of trust exist for — the plumbing that makes public keys into verifiable identities.
A public key lets anyone verify your signatures — but how do you know a public key really belongs to who it claims? If an attacker substitutes their key for the bank's, all the cryptography protects your connection to the attacker. Certificates, CAs, and chains of trust solve 'whose key is this?'
TLS is the protocol securing nearly every connection you make, and it's not a single cryptographic trick — it's the whole toolkit orchestrated into one handshake. Key exchange, certificates, signatures, and authenticated encryption each solve one sub-problem, and TLS composes them so that two parties who've never met can establish a private, tamper-proof, authenticated channel over a hostile network. Understanding the handshake is understanding how every earlier piece fits.
TLS secures nearly every connection you make, and it's not a single trick — it's the whole toolkit orchestrated into one handshake. Key exchange, certificates, signatures, and AEAD each solve one sub-problem, and TLS composes them into a private, authenticated channel over a hostile network.
Every cryptographic guarantee in this series ultimately rests on one thing: the key stays secret and available to exactly the right parties. That's not a math problem — it's an operational one, and it's where real systems fail. A perfect algorithm with a key committed to a Git repo, hardcoded in an image, or never rotated is worthless. Key management is the unglamorous discipline that decides whether all the cryptography actually protects anything.
Every cryptographic guarantee rests on one thing: the key stays secret and available to exactly the right parties. That's not a math problem — it's an operational one, and it's where real systems fail. A perfect algorithm with a key committed to Git is worthless.
The primitives in this series are unbreakable in practice — and yet crypto keeps failing in the real world. That's the paradox of applied cryptography: almost every vulnerability is a misuse of a sound primitive, not a broken one. A predictable random number, a comparison that returns early, a reused nonce, a missing authentication check — each is a one-line mistake that silently voids the guarantee. This closing post catalogs the pitfalls that matter and distills the whole series into a decision guide.
The primitives are unbreakable in practice, yet crypto keeps failing — because almost every vulnerability is a misuse of a sound primitive, not a broken one. A predictable random number, an early-exit comparison, a reused nonce: one-line mistakes that silently void the guarantee. Plus a decision guide.
This series is part of a larger body of work by Pratik Dhanave, an Agentic AI Architect writing about production AI systems, distributed systems, and cloud-native engineering. Explore all course series, browse every post, or find topics via the tag index.