Hashing, MACs, And Integrity

Here's a common confusion: encryption keeps a message secret, but it doesn't tell you if the message was changed in transit. Those are two different jobs done by two different tools. TLS does both, and the second tool — the one that detects tampering — gets less attention than it deserves.

The Problem Encryption Alone Doesn't Solve

Imagine Sarah encrypts the message Transfer $100 to Maria and sends it to her bank. An attacker can't read the encrypted message. Fine. But what if the attacker flips a few bytes — at random — and the message arrives garbled?

Or worse, what if the attacker has been watching encrypted bank transfers and figures out that byte 23 is the first dollar digit, and changes it from 1 to 9? Now Sarah is transferring $900. The bank decrypts the message, doesn't see anything obviously wrong, and processes it.

Encryption hid the message. It did not protect the message from being changed. We need a separate tool for that — integrity.

Hashing — A One-Way Fingerprint

A hash function takes any input — a sentence, a 4 GB video, a database — and produces a fixed-size "fingerprint." For a hash like SHA-256, the fingerprint is exactly 256 bits (64 hex characters) no matter what you feed it.

SHA-256("Hello") → 185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969
SHA-256("Hello.") → 87596de29c33a09c8e3e9f59ca96b5d27a5a44b87dbb3f5b86d5ff6d12c4c5f1

Notice: one extra period turned the entire fingerprint into something completely different. This is the avalanche effect — even a tiny change cascades through the whole hash. Two key properties:

• Deterministic — the same input always produces the same hash;
• One-way — given a hash, you cannot reverse-engineer the input.

Hashes are used everywhere — checking if a file was corrupted in download, storing passwords, verifying software signatures. But hashing alone is not enough for TLS. Here's why.

Why Hashing Alone Doesn't Protect You

If Sarah sends Transfer $100 to Maria along with its hash, an attacker can simply:

• Change the message to Transfer $900 to Eve;
• Compute a new hash of the new message;
• Send the new message with the new hash.

The hash matches. The bank can't tell anything was wrong. Pure hashing checks for accidental corruption, not malicious tampering. You need something the attacker can't recompute.

MAC — Hash + A Shared Secret

A Message Authentication Code (MAC) is a hash that also requires a secret key. You can think of it as MAC = hash(message + secret_key).

Only people who know the secret key can compute the correct MAC. The attacker can change the message, but without the key, they can't produce a valid MAC for the new message. The receiver checks the MAC, sees it doesn't match, and rejects the message.

The most common MAC in TLS is HMAC (Hash-based MAC), built on SHA-256 or SHA-384. You'll see names like HMAC-SHA256 in older TLS configurations.

AEAD — Modern TLS Combines Encryption And Integrity In One Step

Older TLS versions did encryption and MAC as two separate steps — encrypt, then MAC, or MAC then encrypt. The order matters and getting it wrong caused real attacks (BEAST, Lucky 13). Modern cryptographers got tired of this and invented AEAD: Authenticated Encryption with Associated Data.

AEAD ciphers — like AES-GCM and ChaCha20-Poly1305 — do both jobs in a single, optimized operation. Encrypt and authenticate at the same time. No room for ordering bugs.

TLS 1.3, which we'll meet in Section 2, requires AEAD ciphers. The old separate-MAC ciphers are gone in 1.3 — banned by design.

Quick Recap

You'll see the AEAD names in every modern cipher suite. When we read TLS_AES_256_GCM_SHA384 later, the GCM part is the AEAD mode — encryption and integrity in one operation.

What's Still Missing

We've got confidentiality (encryption) and integrity (MAC/AEAD). But how does Sarah's browser know it's actually talking to her bank — and not to an attacker pretending to be the bank? That's the authentication problem, and the answer is certificates. Next chapter.