Why message authentication is not encryption

Two different attackers, two different tools

Security services are easiest to keep straight if you first ask what the attacker is doing. A passive attacker reads traffic and changes nothing: they eavesdrop on a link, capture a session, or study the pattern of who talks to whom. What they take from you is confidentiality, and the tool that answers them is encryption — the message is on the wire, but it is unreadable.

An active attacker changes things: they alter a field in transit, inject a message they invented, replay a genuine message they captured earlier, or masquerade as somebody else. What they take from you is integrity and origin — your confidence that the message says what the sender wrote and came from the sender at all. Encryption does not answer that attacker, and the entire rest of this module exists because it does not.

Message authentication is the procedure that does. A message is authentic when it is genuine and came from its alleged source, and an authentication procedure lets the receiver verify:

1. that the contents are unaltered,
2. that the source is genuine — the message really came from who it claims,
3. optionally, timeliness — the message has not been artificially delayed and replayed, and
4. optionally, sequence — its position relative to the other messages in the exchange is right.

All four sit under the broader service of data integrity. Points 3 and 4 are the two everybody forgets, and they are exactly the two that decide whether a replay attack works.

Worked example — a bit flip that decrypts to nothing useful

Alice sends Bob a payment instruction encrypted under a key only the two of them share. On the wire the ciphertext is 32 bytes. Eve cannot read it. She does not need to: she flips one bit in the eighteenth byte and lets it through.

Bob decrypts. With a block cipher in CBC mode, that single flipped ciphertext bit corrupts the corresponding plaintext bit in one block and randomises the whole of the next block. Bob is now holding something like pay 250 to acc followed by fourteen bytes of noise. He can see that it is noise — but that is a fact about this message, not a security property. Ask the harder question: how does Bob know the noise was Eve's doing and not a line fault? He does not. And now ask the question that actually costs money: if the plaintext had been a 32-byte record of binary fields — an amount, an account number, a flag — the corrupted result would still have decrypted to perfectly well-formed binary. Bob would have processed it.

The lesson is the one sentence to carry out of this lesson: decrypting successfully is not the same as decrypting something authentic. Confidentiality says nobody read it. It says nothing at all about whether anybody changed it.

Three times you want authentication without confidentiality

Authentication is a service in its own right, not a bolt-on to encryption, and there are ordinary situations where you want it alone:

• Broadcast to many destinations. A network-unavailable notice or a control-centre alarm goes to hundreds of hosts. It is cheaper and more reliable to have one destination verify the authentication tag and raise a general alarm on failure than to have every host decrypt every message.
• A receiver too loaded to decrypt everything. A busy server can verify a random sample of arriving messages and still detect a sustained forgery campaign, which decryption-of-everything would have cost it far more to learn.
• A program that must run in the clear. An executable that has to be launched without a per-execution decryption step can still ship with an authentication tag, so its integrity is checkable on demand while its contents stay public.

Notice what all three have in common: the contents are not secret, and the provenance is the thing worth protecting.