What cryptography guarantees: the map of primitives

People say "we'll encrypt it" the way they say "we'll secure it," as if cryptography were one thing that makes data safe. It isn't. Cryptography is a set of distinct tools, and each one answers a different question — "can an eavesdropper read this?" is a completely separate question from "can I tell if this was tampered with?" or "is this really from who it claims?" Reach for encryption when you actually needed a signature, or bolt a MAC on wrong, and you get something that looks secure and isn't. So before any single primitive, you need the map: which guarantees exist, and which tool provides each.

The frame for this whole module: cryptography provides a few precise guarantees — confidentiality, integrity, and authenticity — and each is delivered by a specific family of primitives. Real systems layer several primitives together, and security comes from picking the right ones and using them correctly.

The three guarantees

Almost everything in cryptography serves one of three goals. Keep them separate in your head, because conflating them is the root of most mistakes.

Confidentiality — nobody but the intended recipient can read the content. This is what "encryption" provides: transform the data with a key so it's unintelligible to anyone without the key. Note what confidentiality does not give you: an encrypted message can still be altered in transit by someone who can't read it, and encryption alone doesn't prove who sent it.

Integrity — you can detect if the data was changed. Even one flipped bit should be catchable. This is provided by hash functions, and by MACs and signatures built on them. Integrity is orthogonal to secrecy: you often want to verify that a public file wasn't corrupted or tampered with, no encryption involved.

Authenticity — the data really came from who it claims to. A message can be confidential and intact and still be from an impostor. Authenticity (and its stronger cousin non-repudiation — the sender can't later deny it) comes from MACs (shared-key) and digital signatures (public-key).

The primitive families

Each guarantee is delivered by a family of primitives. Here's the whole toolbox, each of which gets its own lesson:

• Hash functions (lesson 2) — a one-way function turning any input into a fixed-size fingerprint; the basis of integrity, and (used correctly) password storage (lesson 3).
• Symmetric encryption (lesson 4) — one shared key encrypts and decrypts; fast, used for bulk data (AES).
• Public-key (asymmetric) encryption (lesson 5) — a pair of keys, one public and one private; solves the problem of how two strangers agree on a key at all.
• MACs and digital signatures (lesson 6) — integrity and authenticity; MACs with a shared key, signatures with a key pair.
• Key exchange (lesson 7) — how two parties derive a shared secret over a channel everyone can see (Diffie-Hellman), the trick that makes the whole web work.
• Secure randomness (lesson 8) — unpredictable random numbers, which every key, nonce, and IV silently depends on.

The dependencies matter: symmetric encryption needs a shared key, which key exchange establishes, which needs randomness to be unpredictable. The families aren't independent — they're layers.

Two rules that prevent most disasters

Cryptography has a reputation for being treacherous, and it is — but the traps are surprisingly consistent. Two principles keep you out of almost all of them.

Kerckhoffs's principle: the security must live in the key, not in the secrecy of the algorithm. A cryptosystem should remain secure even if an attacker knows every detail of how it works — everything except the key. This is why real cryptographic algorithms are public, standardized, and endlessly scrutinized: an algorithm that's only safe while its design is secret ("security through obscurity") has never actually been tested, and secrets about design always leak. Strong crypto is strong in the open.

Don't roll your own crypto. Not because the math is beyond you, but because secure implementation is a minefield that has little to do with the math — reusing a nonce, comparing secrets with a non-constant-time equality (leaking them via timing), a biased random source, the wrong cipher mode. The primitives themselves are rarely broken; they're misused. The professional move is to use a vetted library's high-level, hard-to-misuse interface, and to understand the primitives well enough to use them correctly — which is exactly what this module is for. Understanding is the goal; reimplementing is not.

Systems are primitives, combined

No real security protocol is a single primitive. Consider what happens when you load an HTTPS page — the TLS handshake — because it's the canonical example and this module ends by returning to it. In one connection setup, TLS uses: a key exchange to agree on a shared secret over the open internet, public-key signatures and certificates to prove the server is who it claims (authenticity), symmetric AEAD encryption to protect the actual bytes efficiently (confidentiality + integrity), hashes throughout, and secure randomness underlying all the keys and nonces. Every family on the map, composed into one protocol. You already met one piece of this — the Diffie-Hellman key exchange — in the networking track; this module builds up every other piece and then shows how they lock together.

That's the shape of the module: learn each primitive and the exact guarantee it provides, learn the ways each is misused, and finish by seeing them assembled into the thing that secures the web.

Where this goes next

We start with the most broadly useful primitive, and the one the others are built from: the hash function. It looks almost too simple — turn any input into a fixed-size fingerprint — but the precise properties it must have (one-wayness, collision resistance, the avalanche effect) are what make integrity, commitments, and password storage possible, and getting those properties clear is the foundation for everything after.

Go deeper

• MDN — Web security — Where these guarantees show up in the browser platform — the applied side of the primitives mapped here.
• Crypto 101 — A free, from-scratch course covering this same primitive map in depth, with the attacks that motivate 'don't roll your own.'
• MDN — Web Crypto API — The browser's vetted implementation of these primitives (SubtleCrypto) — the 'use a library' path this lesson recommends.

Check yourself

Answer out loud, as if an interviewer asked. If you hand-wave, reread that section.

1. Name the three core guarantees and, in one phrase each, what question they answer.
2. Why is 'we encrypted it' not a complete security statement? Give a concrete way encrypted-but-unauthenticated data can still be attacked.
3. Match each primitive family to the guarantee(s) it provides: hash, symmetric encryption, public-key encryption, MAC, digital signature.
4. State Kerckhoffs's principle and explain why real cryptographic algorithms are public rather than secret.
5. Why is 'don't roll your own crypto' about implementation rather than the underlying math? Give two example misuse traps.
6. The primitive families are layered, not independent. Trace the dependency from bulk symmetric encryption down to randomness.
7. TLS is 'primitives combined.' List which family provides each of: agreeing on a shared key, proving the server's identity, and protecting the actual bytes.