Three jobs, three tools
In the previous guide you met the threats and you met the goals: the CIA triad of confidentiality, integrity, and availability. Cryptography is mostly about the first two. It does three concrete jobs, and the whole subject is much friendlier once you keep them apart. Confidentiality means only the intended reader can understand the message — that is the job of encryption. Integrity means you can tell if even a single bit was changed in transit — that is the job of hashes and MACs. Authenticity means you can prove who actually sent something — that is the job of digital signatures.
A crucial warning before we start: do not confuse these jobs. Encrypting a message does NOT prove who sent it, and it does NOT guarantee nobody tampered with it. A message can be perfectly secret and still be a forgery, or arrive scrambled. This is exactly the mistake that lets a clever attacker slip through, so we will treat secrecy, integrity, and authenticity as three separate problems that happen to be solved with related maths.
Confidentiality: shared keys and the distribution problem
The oldest idea is symmetric-key encryption: both sides share one secret key, and the same key both locks and unlocks the message. Think of a strongbox with a single physical key that has been copied twice — one for you, one for your friend. Modern symmetric ciphers like AES are extremely fast and effectively unbreakable when used correctly, so almost all bulk data on the Internet is ultimately protected this way. The plaintext goes in, the key scrambles it into ciphertext that looks like random noise, and only the matching key turns it back.
But there is a chicken-and-egg snag, and it is the central drama of all cryptography: the key-distribution problem. To talk secretly to a website you have never visited, you both need the same secret key first — but the only channel you have to agree on it is the very Internet you do not trust. If you mail the key over the open network, the eavesdropper from the last guide simply copies it. You cannot encrypt the key, because encrypting it would need a key you have not shared yet. Symmetric crypto alone cannot bootstrap trust between strangers.
The fix is the most beautiful idea in the field: public-key cryptography. Each party generates a matched pair of keys — a public key it can shout to the world, and a private key it tells no one. The two are mathematically linked so that whatever one key locks, only the other can unlock. Now the trick: if I encrypt a message with your public key, only your private key can open it. I can find your public key anywhere, even shout it across the untrusted Internet, and the eavesdropper learns nothing useful — because the public key only locks, it cannot unlock. The padlock-and-mailbox picture below makes it click.
Alice wants to send a secret to Bob: Bob's public key = an open padlock Bob mailed everywhere Bob's private key = the only key that opens that padlock Alice: puts message in box, snaps Bob's padlock shut -> ciphertext Anyone on the wire: sees a locked box, cannot open it Bob: uses his private key (kept secret) -> plaintext Nobody ever had to share a secret in advance.
Public-key maths is slow — far too slow to encrypt a whole video call. So the real Internet uses a hybrid: public-key crypto does the small, hard job of agreeing on a fresh symmetric key (or doing a key exchange), and then fast symmetric crypto encrypts the actual data. That handshake is exactly what TLS does at the start of every HTTPS connection, which is the subject of the next guide.
Integrity: hashes and MACs
Secrecy is not enough. An attacker who cannot read your message might still flip bits to corrupt it, or splice in their own. To catch that, we need integrity — a way to detect any change. The tool is a cryptographic hash: a function that takes any amount of data and produces a short, fixed-size fingerprint, say 256 bits. Two properties make it magic. It is one-way (you cannot work backwards from the fingerprint to the data), and it is collision-resistant (you cannot find two different inputs with the same fingerprint). Change one comma in a gigabyte file and the entire fingerprint changes unrecognisably.
That secret is what turns a hash into a message authentication code, or MAC. A MAC hashes the message together with a shared secret key, so only someone who holds the key can produce a valid tag. The receiver, who also holds the key, recomputes the tag and checks it matches. The standard recipe is HMAC, which carefully folds the key into a hash function twice to avoid subtle attacks. A correct MAC proves two things at once: the message was not altered, and it came from someone who knows the key. Notice it gives you integrity AND a kind of authenticity — but only between people who already share the secret key.
Authenticity: digital signatures
A MAC has a limit: because the verifying key is the same secret as the signing key, anyone who can check a MAC could also forge one. That is fine between two trusting partners, but useless for proving to the whole world that a message is genuinely from you. For that we run public-key cryptography backwards to get a digital signature. To sign, you use your PRIVATE key on a hash of the message; to verify, anyone uses your matching PUBLIC key. Only you could have produced the signature (private key is secret), yet everyone can check it (public key is public).
This neatly inverts the encryption picture. For secrecy you lock with the recipient's public key so only they can open it. For a signature you lock with your own private key so anyone can open it — and the fact that the public key opens it proves only you could have locked it. In practice you do not sign the whole document; you hash it first and sign the short fingerprint, which is faster and binds the signature to the exact bytes. Walk through the steps:
- Sign: the sender computes a cryptographic hash of the message, then encrypts that hash with their own private key. The result is the signature, sent alongside the message.
- Verify, part one: the receiver decrypts the signature using the sender's public key, recovering the hash the sender claimed.
- Verify, part two: the receiver independently hashes the message it actually received.
- Compare: if the two hashes match, the message is unaltered AND it really came from the holder of that private key. If they differ, reject it — something was tampered with or forged.
Signatures also give you a bonus the CIA triad sometimes lists separately: non-repudiation. Because only the private-key holder could have signed, they cannot later deny having done so. But notice a quiet assumption hiding in step two: to verify, you need the sender's genuine public key. How do you know a public key really belongs to your bank, and not to the man in the middle who handed you his own key while pretending to be the bank? Signatures move the trust problem; they do not erase it.
Putting it together, and what cryptography does not promise
Now you can see how the pieces interlock. Public-key crypto solves key distribution by letting strangers agree on a shared secret over an open line. That shared secret feeds fast symmetric encryption for confidentiality. A MAC (or signature) rides along for integrity and authenticity, so the receiver can detect tampering and confirm the sender. This exact stack is what TLS assembles to protect HTTPS, and it is why the dangerous man-in-the-middle attack from the last guide is so much harder to pull off on an encrypted, authenticated channel.
But be honest about the limits. Cryptography secures a message in transit; it says nothing about whether the person you are talking to is honest, or whether the server you reached is the one you meant. The biggest open question is still that genuine-public-key problem: binding a key to a real-world identity. That is solved not by more maths but by certificates and certificate authorities — the trust machinery of the next guide. Cryptography also cannot help if your own device is compromised, if you reuse a weak password, or if you are simply tricked into typing your secret into a fake site.
One last honest note, because it gets hyped. Quantum computers threaten some of today's public-key maths, which is why people are rolling out post-quantum algorithms. And quantum key distribution secures a key exchange using the laws of physics — but it does not by itself encrypt your data, and it does not make the rest of cryptography obsolete; you still need symmetric ciphers, hashes, and signatures. Same toolbox, sturdier locks. With the three jobs straight in your head — secrecy by keys, integrity by hashes and MACs, authenticity by signatures — you are ready to see how the whole web bootstraps trust.