A developer authenticates messages by computing Tag = SHA-256(key || message), appending the raw key before the message. Why is this insecure, and what construction fixes it?
Think about your answer, then reveal below.
Model answer: SHA-256 uses Merkle-Damgard construction, which is vulnerable to length extension attacks. An attacker who sees Tag = SHA-256(key || message) can compute SHA-256(key || message || padding || extra) without knowing the key, because the tag IS the internal state after processing (key || message). This lets them forge valid tags on extended messages. HMAC fixes this by using a nested construction: HMAC(k, m) = H((k XOR opad) || H((k XOR ipad) || m)), which prevents length extension by hiding the internal state behind an outer hash.
The length extension vulnerability is specific to Merkle-Damgard hashes. HMAC's nested structure ensures the inner hash's output is processed through the outer hash with a different key derivation, so knowing HMAC(k, m) reveals nothing about the internal state needed to extend the computation. HMAC is provably secure as a MAC assuming the compression function of the hash is a PRF.
Question 2 Multiple Choice
Encryption provides confidentiality. A MAC provides integrity and authenticity. Why doesn't encryption alone provide integrity?
AEncryption algorithms are designed to be reversible, and any reversible function can be manipulated by an adversary
BStandard encryption (without authentication) is malleable — an attacker can modify ciphertext in ways that produce predictable changes to the plaintext upon decryption, without detection. For example, flipping a bit in CTR-mode ciphertext flips the corresponding plaintext bit
CEncryption keys are typically shorter than MAC keys, providing less security
DDecryption always succeeds regardless of input, so corrupted ciphertext looks like a valid but different message
Malleability is the core issue. In CTR mode, c = p XOR keystream, so flipping ciphertext bit i flips plaintext bit i — the attacker controls exactly which bit changes. In CBC mode, manipulating ciphertext block i garbles plaintext block i but allows precise bit flips in block i+1. Without a MAC or authentication tag, the recipient decrypts the modified ciphertext and gets a modified plaintext with no indication of tampering. This is why authenticated encryption (encrypt + MAC, or integrated modes like GCM) is essential.
Question 3 True / False
CBC-MAC is secure for fixed-length messages but insecure for variable-length messages without modification.
TTrue
FFalse
Answer: True
For fixed-length messages, CBC-MAC is provably secure as a PRF. But for variable-length messages, an attacker can forge tags: given the tag t1 on a one-block message m1 (where t1 = E_k(m1)), the attacker can compute a valid tag on the two-block message (m1 || (m1 XOR t1)) because the second block's encryption input is t1 XOR (m1 XOR t1) = m1, producing t1 again. Variants like CMAC (which uses a final key-dependent transformation) or EMAC (which encrypts the CBC-MAC output with a second key) fix this.
Question 4 Short Answer
A MAC guarantees that the message was sent by someone who knows the key, but it cannot prove which of the two key-holders sent it. Why is this a limitation compared to digital signatures?
Think about your answer, then reveal below.
Model answer: Since both sender and receiver share the same secret key, either party could have computed the tag. The receiver cannot prove to a third party that the sender (specifically) created the message, because the receiver could have forged it themselves. Digital signatures use asymmetric keys: only the holder of the private key can sign, while anyone with the public key can verify. This provides non-repudiation — the signer cannot plausibly deny having signed.
MACs provide authentication between two parties who trust each other enough to share a key, but not accountability to third parties. This distinction matters in legal, financial, and protocol design contexts where proof of origin (not just integrity) is required.
Question 5 Multiple Choice
HMAC uses two hash invocations. Why can't a single invocation H(key || message) serve as a secure MAC?
AA single invocation is too slow for practical use
BH(key || message) is vulnerable to length extension with Merkle-Damgard hashes. HMAC's two-pass structure prevents this and is provably secure assuming the hash's compression function is a PRF
CThe hash function needs to process the key twice to achieve 256-bit security
DSingle invocation MACs can only handle fixed-length messages
With Merkle-Damgard hashes (SHA-256, etc.), H(key || message) leaks the internal state as the output, enabling length extension. HMAC's construction H(k2 || H(k1 || m)) with derived keys k1 and k2 ensures the inner hash's output goes through a second keyed hash pass, preventing state exposure. The formal security proof shows HMAC is a PRF (and therefore a secure MAC) if the compression function of H is a PRF — a weaker assumption than collision resistance.