Digital signature versus MAC — four attacks, four different answers

What a digital signature is, precisely

FIPS 186-4 defines a digital signature as a cryptographic transformation of data that provides three services: origin authentication, data integrity, and signatory non-repudiation. Learn all three words; the third one is the answer to half of the scenarios below.

The sequence is short. The sender computes a hash of the message; encrypts that hash with the sender's private key — mode (b) from L5.1 — and that encrypted hash is the signature; and transmits the message together with the signature. The recipient computes the hash of the message they actually received, decrypts the signature with the sender's public key, and compares. If the two agree, the message is unaltered and was signed by the holder of that private key. FIPS 186-4 specifies three algorithms for this: DSA, RSA and ECDSA.

Two properties follow immediately. A signature provides no confidentiality — the message travels beside it in the clear, and even signing the whole message rather than its hash would leave it readable by anyone with the public key. And the private key is held by exactly one party, which is the asymmetry the next section turns on.

Worked example — four attacks, both tools

Rina sends Naseem a message in the form $M=x\Vert \mathrm{auth}(x)$, where x is the content and $\mathrm{auth}(x)$ is either a MAC computed under a key Rina and Naseem share, or a digital signature made with Rina's private key. Work each attack against both tools.

(a) Oscar alters the message in transit. He changes x to x' but cannot produce a matching $\mathrm{auth}(x^{\prime })$. Naseem recomputes the authenticator over the x' he received and it does not match what arrived. Both tools detect it. The MAC works because Oscar lacks the shared key; the signature works because Oscar lacks Rina's private key. Detection is the same mechanism in both cases — recomputation fails to match — and saying so is what earns the mark.

(b) Oscar captures a genuine message and sends it again later. He changes nothing. Naseem recomputes the authenticator and it matches perfectly — because the message really is authentic. It is Rina's content and Rina's authenticator; it is simply arriving for the second time. Neither tool detects it. Integrity was never the problem, and no amount of cryptographic strength in $\mathrm{auth}$ helps. The fix is to make the message unrepeatable by putting freshness inside the authenticated data: a sequence number, a timestamp, or a nonce covered by $\mathrm{auth}(x)$, so a replayed copy is recognisably stale.

(c) A third party, Oscar, claims Rina sent him a message that she did not. With a digital signature, Oscar is stuck: producing $\mathrm{auth}(x)$ requires Rina's private key, which he does not have, so he cannot fabricate one and cannot even alter a real one. Only the signature settles this. With a MAC, both Rina and Naseem hold the shared key, so a valid MAC proves only that someone holding that key produced it — which is two people. If Oscar had somehow obtained the key, a MAC would identify nobody at all.

(d) Naseem himself cheats: he fabricates a message and claims Rina sent it. This is (c) with the recipient as the attacker, and it is the sharpest case. With a MAC, Naseem holds the very key the MAC is computed under, so he can generate a perfectly valid $x\Vert \mathrm{auth}(x)$ for any x he likes. Rina cannot disprove it, and no third party can adjudicate. With a digital signature, Naseem holds only Rina's public key, which verifies signatures and cannot make them. Only the signature protects Rina.

Cases (c) and (d) are the same fact seen from two sides: a MAC key is shared, so anything one party can produce the other can produce too. That symmetry is exactly why a MAC gives no non-repudiation, in either direction, and why non-repudiation requires an asymmetric secret — something exactly one party holds.

The digital envelope

Public-key encryption is far too slow for bulk data, and symmetric encryption needs a key both ends already share. The digital envelope resolves the deadlock. The sender generates a random one-time symmetric key, encrypts the message under it with a fast symmetric cipher, encrypts that one-time key under the recipient's public key, and sends both parts together. The recipient recovers the one-time key with their private key and decrypts the message with it.

That is how public-key cryptography is actually used on real traffic, and it is the practical answer to misconception 2. Note carefully what it does not give: an envelope provides confidentiality only. It is a sealed envelope containing an unsigned letter — the recipient knows nobody read it, and knows nothing about who wrote it. Adding a signature is a separate composition, not a property of the envelope.