CBS 324 Cryptography

Message Authentication Code (MAC)

Types of Cryptographic Hash Functions
Message Authentication
Integrity:

𝐀𝐥𝐢𝐜𝐞 interferes with the transmission 𝐁𝐨𝐛

(modifies the message, or inserts
a new one)

How can 𝐁𝐨𝐛 be sure that

𝑴 really comes from 𝐀𝐥𝐢𝐜𝐞?
Sometimes secrecy more important!

transfer $𝟏𝟎𝟎𝟎 to Bob

transfer $𝟏𝟎𝟎𝟎 to Eve

Alice Bank

Of course: usually we want both secrecy and integrity.

Does encryption guarantee message integrity?

Idea:
1. Alice encrypts 𝒎 and sends 𝒄 = 𝐄𝐧𝐜(𝒌, 𝒎) to Bob.
2. Bob computes 𝐃𝐞𝐜(𝒌, 𝒎), and if it “makes sense” accepts it.
Hope: only Alice knows 𝒌, so nobody else can produce a valid ciphertext.

This doesn’t work!

Example: one-time pad.

plaintext 𝒎 transfer $𝟏𝟎𝟎𝟎 to 𝐁𝐨𝐛

key 𝒌 If Eve knows 𝒎 and 𝒄 then she can

calculate 𝒌 and produce a ciphertext
xor of any other message
ciphertext 𝒄
 A signing algorithm efficiently returns a tag given the key and
What do we need? the message. A verifying algorithm efficiently verifies the
authenticity of the message given the same key and the tag

A separate tool for authenticating messages.

This tool will be called

Message Authentication Codes
(MACs)

A MAC is a pair of algorithms

(𝐓𝐚𝐠, 𝐕𝐫𝐟𝐲)

“tagging” algorithm “verification algorithm”

 A mathematical view
K – key space
M – plaintext space
T - set of tags

A Message Authentication Code (MAC) scheme is a pair (𝐓𝐚𝐠, 𝐕𝐫𝐟𝐲), where

 Tag: K × M → T is a tagging algorithm,
 Vrfy: K × M × T → {yes, no} is a verification algorithm.

We will sometimes write 𝐓𝐚𝐠𝒌(𝒎) and 𝐕𝐫𝐟𝐲𝒌(𝒎, 𝒕) instead of

𝐓𝐚𝐠(𝒌, 𝒎) and 𝐕𝐫𝐟𝐲(𝒌, 𝒎, 𝒕).
Message Authentication Codes
Eve can see (𝒎, 𝒕 = 𝐓𝐚𝐠𝒌(𝒎))

She should not be able to compute a

valid tag 𝒕’ on any other message 𝒎’.

(𝒎, 𝒕 = 𝐓𝐚𝐠𝒌(𝒎)) checks if

𝒎 𝐕𝐫𝐟𝐲𝒌 𝒎, 𝒕 ∈ {𝐲𝐞𝐬, 𝐧𝐨}
𝐀𝐥𝐢𝐜𝐞 Bob

𝒌 𝒌
𝒌 is chosen randomly
from some set K
Correctness
it always holds that:
𝐕𝐫𝐟𝐲𝒌(𝒎, 𝐓𝐚𝐠𝒌(𝒎)) = 𝐲𝐞𝐬.
Message authentication – multiple messages

𝒎𝟏 𝒕𝟏 = 𝐓𝐚𝐠𝒌(𝒎𝟏)
𝒎𝟐 𝒕𝟐 = 𝐓𝐚𝐠𝒌(𝒎𝟐)
...

...
𝐀𝐥𝐢𝐜𝐞 Bob
𝒎𝒘 𝒕𝒘 = 𝐓𝐚𝐠𝒌(𝒎𝒘 )

𝒌 𝒌

Eve should not be able to

compute a valid tag 𝒕’ on any
other message 𝒎’.
Agreements

If 𝐕𝐫𝐟𝐲𝒌(𝒎, 𝒕) = 𝐲𝐞𝐬 then we say that 𝒕 is a valid tag on the message 𝒎.

If Tag is deterministic, then Vrfy just computes Tag and compares the result.

In this case we do not need to define Vrfy explicitly.

How to define security?
We need to specify:

1. how the messages 𝒎𝟏, … , 𝒎𝒘 are chosen,

2. what is the goal of the adversary.

Good tradition: be as pessimistic (doubtful) as possible!

We assume that:
1. The adversary is allowed to chose 𝒎𝟏, … , 𝒎𝒘 .
2. The goal of the adversary is to produce a valid tag on
some 𝒎’ such that 𝒎’ ∉ {𝒎𝟏, … , 𝒎𝒘 } .
 security parameter
selects a random 𝒌 ∈ {𝟎, 𝟏}𝒏
𝟏𝒏

𝒎𝟏
adversary
(𝒎𝟏, 𝒕 = 𝐓𝐚𝐠𝒌(𝒎𝟏))
oracle

...
𝒎𝒘

(𝒎𝒘 , 𝒕 = 𝐓𝐚𝐠𝒌(𝒎𝒘 ))

We say that the adversary breaks the MAC scheme at the end she
outputs (𝒎’, 𝒕’) such that
𝐕𝐫𝐟𝐲𝒌(𝒎’, 𝒕’) = 𝐲𝐞𝐬
and
𝒎’ ∉ {𝒎𝟏, … , 𝒎𝒘 }
Warning: MACs do not offer protection against the “replay attacks”.

(𝒎, 𝒕)

𝐀𝐥𝐢𝐜𝐞 𝐁𝐨𝐛

Since Vrfy is stateless there is no

way to detect that (𝒎, 𝒕) is not
fresh!

This problem has to be solved by the higher-level application

(methods: time-stamping, nonces...).
Constructing a MAC
1. There exist MACs that are secure even if the adversary is infinitely-
powerful.
These constructions are not practical.

2. MACs can be constructed from the block-ciphers.

We will now discuss to constructions:
• simple (and not practical),
• a little bit more complicated (and practical) – a CBC-MAC

3. MACs can also be constructed from the hash functions NMAC, HMAC).
 A simple construction from a block cipher

Let
𝑭 ∶ {𝟎, 𝟏}𝒏 × {𝟎, 𝟏}𝒏 → {𝟎, 𝟏}𝒏

𝑭(𝒌, 𝒎)
be a block cipher (a PRF).

We can now define a MAC scheme that works only

for messages 𝒎 ∈ {𝟎, 𝟏}𝒏 as follows:
𝒌 𝑭𝒌
𝐓𝐚𝐠(𝒌, 𝒎) = 𝑭(𝒌, 𝒎)

It can be proven that it is a secure MAC. 𝒎

How to generalize it to longer messages?

 The Idea
Add a fresh random value, length, counter value to each block!

𝑭(𝒌, 𝒙𝟏) 𝑭(𝒌, 𝒙𝒅 )

...
𝑭𝒌 𝑭𝒌

r l 1 m1 r l d md

𝒙𝟏 𝒙𝒅

This works!
 𝐓𝐚𝐠𝒌(𝒎)

𝒓 𝑭(𝒌, 𝒙𝟏) 𝑭(𝒌, 𝒙𝟐) 𝑭(𝒌, 𝒙𝒅 )

𝑭𝒌 𝑭𝒌 ... 𝑭𝒌

𝒓 ℓ 𝟏 𝒎𝟏 𝒓 ℓ 𝟐 𝒎𝟐 ... r ℓ 𝒅 𝒎𝒅

𝒙𝟏 𝒙𝟐 𝒙𝒅

𝒓 is chosen randomly ...

𝒎𝟏 𝒎𝟐 𝒎𝒅
𝒎 𝟎𝟎𝟎
𝒏 – block length ℓ

pad with zeroes if needed

A new member of “Minicrypt”

one-way functions
exist

this can be proven this we already knew

computationally-secure PRPs/PRFs
MACs exist exist

this we have just

shown
 𝐓𝐚𝐠𝐤(𝒎)

𝑭𝒌 𝑭𝒌 𝑭𝒌 𝑭𝒌 𝑭𝒌

|𝒎| 𝒎𝟏 𝒎𝟐 𝒎𝟑 ... 𝒎𝒅

Why is this
needed?

Suppose we do not prepend |𝒎|...

 𝒕𝟏 = 𝐓𝐚𝐠𝒌(𝒎𝟏) 𝒕𝟐 = 𝐓𝐚𝐠𝒌(𝒎𝟐)
the adversary
chooses:
𝑭𝒌 𝑭𝒌

𝒎𝟏 𝒎𝟐

𝒕’ = 𝐓𝐚𝐠𝒌(𝒎’)
𝒕𝟏 𝒕’ = 𝒕𝟐

now she can

𝑭𝒌 𝑭𝒌
compute:
𝒎𝟐
𝒎𝟏 𝒎 𝟐 ⊕ 𝒕𝟏

𝒎’
A better idea
M. Bellare, R. Canetti, and H. Krawczyk (1996):

• NMAC (Nested MAC)

• HMAC (Hash based MAC)

have some “provable properties”

They both use the Merkle-Damgård transform.

Again, let 𝒉: {𝟎, 𝟏}𝟐𝑳 → {𝟎, 𝟏}𝑳 be a compression function.

HMAC
• General comment: HMAC treats the hash function as a “black box.”

• The two important objectives to the acceptability of HMAC.

1st an existing implementation of a hash function can be used as a module in

implementing HMAC. (Advantage: so bulk of HMAC code is prepackaged and ready to use without
modification).

2nd if faster hash function available remove existing hash function module and drop the
new module. Replacing SHA2 with SHA3 since security of HMAC retained simply by replacing the
embedded hash function with a more secure one.

• Main advantage of HMAC over other proposed hash-based schemes? HMAC can be proven secure
provided that the embedded hash function has some reasonable cryptographic strengths.

In HMAC, the ipad and opad are two fixed values used in the key expansion process.
1. The ipad (inner pad) is a sequence of bytes used to XOR with the secret key before hashing the message.
2. The opad (outer pad) is another sequence of bytes used to XOR with the secret key after hashing the message
HMAC Structure • H = embedded hash function (e.g., MD5, SHA-1, RIPEMD-160)
• IV = initial value input to hash function
• M = message input to HMAC (including the padding specified
in the embedded hash function)
• Yi = i th block of M, 0 … i … (L - 1)
• L = number of blocks in M
• b = number of bits in a block
• n = length of hash code produced by embedded hash
function
• K = secret key; recommended length is n; if key length is
greater than b, the key is input to the hash function to
produce an n-bit key
• K+ = K padded with zeros on the left so that the result is b
bits in length

Then HMAC can be expressed as

HMAC(K, M) = H[(K+ ⊕ opad) || H[(K+ ⊕ ipad)||M]]

HMAC Structure

We can describe the algorithm as follows.

1. Append zeros to the left end of K to create a b-bit string K+

(e.g., if K is of length 160 bits and b = 512, then K will be
appended with 44 zeroes).
2. XOR (bitwise exclusive-OR) K+ with ipad to produce the b-bit
block Si .
3. Append M to Si .
4. Apply H to the stream generated in step 3.
5. XOR K+ with opad to produce the b-bit block So.
6. Append the hash result from step 4 to So.
7. Apply H to the stream generated in step 6 and output the
result.
Efficient Implementation of HMAC
What is needed to establish secure channels?

In practice one needs both

encryption
and
authentication.

This can be achieved as follows:

• combine encryption with authentication
or
• design “authenticated encryption” from scratch.
 Authenticated Encryption (AE)
• AE: simultaneously protect confidentiality and authenticity (integrity) of communications. Many applications
and protocols require both forms of security, but until recently the two services have been designed separately.
There are four common approaches to providing both confidentiality and encryption for a message M.

• Hashing followed by encryption (H → E): 1st cryptographic hash function over M as h = H(M). Then encrypt
message plus hash function: E(K, (M} h)).

• Authentication followed by encryption (A → E): Use two keys. 1st authenticate plaintext by computing the MAC
value as T = MAC(K1, M). Then encrypt message plus tag: E(K2, [M}T]). Applied on SSL/TLS protocols

• Encryption followed by authentication (E → A): Use two keys. 1st encrypt message to yield the ciphertext C =
E(K2, M). Then authenticate the ciphertext with T = MAC(K1, C) to yield the pair (C, T). Applied on IPSec protocol

• Independently encrypt and authenticate (E + A). Use two keys. 1st Encrypt message to yield ciphertext C = E(K2,
M). Then Authenticate plaintext with T = MAC(K1, M) to yield pair (C, T). Applied on SSH protocol

• Both decryption and verification are straightforward for each approach.

For H → E, A → E, and E + A, decrypt first, then verify. For E → A, verify first, then decrypt.
 Authentication + encryption, options:
• Encrypt-and-authenticate:
𝒄 ∶= 𝐄𝐧𝐜𝒌𝟏 (𝒎) and 𝒕 ≔ 𝐓𝐚𝐠 𝒌 𝟐 (𝒎), send (𝒄, 𝒕)
wrong
𝒄 ∶= 𝐄𝐧𝐜𝒌𝟏 (𝒎) 𝒎 𝒕 ≔ 𝐓𝐚𝐠 𝒌 𝟐 (𝒎)

• Authenticate-then-encrypt:
𝒕 ∶= 𝐓𝐚𝐠 𝒌 𝟐 (𝒎) and 𝒄 ≔ 𝐄𝐧𝐜𝒌 𝟏 (𝒎||𝒕), send 𝒄
better
𝒄 ≔ 𝐄𝐧𝐜𝒌 𝟏 (𝒎||𝒕) 𝒎 𝒕 ≔ 𝐓𝐚𝐠 𝒌 𝟐 (𝒎)

• Encrypt-then-authenticate:
𝒄 ≔ 𝐄𝐧𝐜𝒌𝟏 (𝒎) and 𝒕 ≔ 𝐓𝐚𝐠 𝒌 𝟐 (𝒄), send (𝒄, 𝒕)
the best

𝒕 ≔ 𝐓𝐚𝐠 𝒌 𝟐 (𝒄) 𝒎 𝒄 ≔ 𝐄𝐧𝐜𝒌𝟏 (𝒎)