Engineer's toolkit
Cryptography for engineers
The few building blocks you need for everyday security decisions, which question each one answers, and where teams go wrong. Start here for the map.
You will almost never implement a cryptographic algorithm, and you should not. But every week you will make cryptographic decisions. How do you store a password? How do you check a webhook? How do you make a reset token? Getting these wrong rarely fails a test. It shows up later as a breach.
Engineers need only a small set of building blocks. Each one answers one question. Has this data changed? Did it come from someone holding the key? Can anyone else read it? Learn which block answers which question, learn the common ways each one is misused, and use a well-reviewed library.
Start with the goal
Security people name four properties:
- Integrity: the data has not changed.
- Authenticity: the data came from a key holder.
- Confidentiality: only key holders can read it.
- Non-repudiation: a third party can prove who made it.
Most bugs come from using a tool for one property and assuming it gives another. A plain hash checks integrity against accidents, but anyone can recompute it, so it proves nothing about who made the data. A shared-key tag proves authenticity to the two key holders, but it can't show which one made it. Only a signature can.
Concepts in this topic
| Step | Concept | What it answers |
|---|---|---|
| 1 | Hash functions | What makes a digest hard to fake? |
| 2 | Secure randomness and tokens | Where should keys and tokens come from? |
| 3 | HMAC and webhook signing | How do I detect tampering with a shared key? |
| 4 | AEAD and envelope encryption | How do I encrypt data and keep the keys safe? |
| 5 | Public-key crypto and signatures | How do I let others verify, without letting them sign? |
| 6 | Password hashing | How do I store passwords so guessing is slow? |
Common mistakes
- Using a hash where you need a MAC, or a MAC where you need a signature.
- Designing your own construction, such as "AES, then a SHA-256 of the output".
- Keeping keys in the same database or repository as the data they protect.
- Trusting tests to catch crypto bugs. Most broken crypto passes them.
At work
For everyday choices, pick the standard primitive and a well-reviewed library. Escalate to the security team when you design a new protocol, handle payment card data (PCI DSS), need FIPS compliance, or run key ceremonies and HSM setup.
In design reviews and interviews, name the property first. "We need authenticity that third parties can verify, so a signature, not an HMAC." Then name the primitive, then the operations: where the key lives, how it rotates, and who can decrypt.
Key takeaways
- Map each goal to a primitive. Integrity with a shared key is HMAC. Public verification is a signature. Secrecy is an AEAD. Passwords need a slow hash. Tokens need a CSPRNG.
- Use high-level libraries, and avoid knobs you don't need.
- Most of the hard work is key management, not the cipher.
Further learning
Latacora's list of which primitive to use for which job is short and blunt. It's the best single page to bookmark.
Cryptographic Right Answers (Latacora)https://www.latacora.com/blog/cryptographic-right-answers/latacora.com Crypto 101: a free introductory book by Laurens Van HoutvenCrypto 101crypto101.io The Cryptopals Crypto Challengescryptopals.comRelated
Hash functions
A hash turns any input into a fixed-size fingerprint. A secure hash is hard to reverse and hard to collide, and MD5 and SHA-1 no longer meet that bar.
HMAC and webhook signing
A keyed hash proves a message came from a key holder and was not changed. It protects webhooks, signed URLs and TOTP codes.
Password hashing
Passwords need slow, salted, memory-hard hashes. How the guessing math works, which algorithm to pick, and how to tune the cost for your login servers.