HMAC

a long message needs to put into MAC protocol

MAC is a specific type of PRF

hash then MAC

if one can find collisions in H, then the hash-then-MAC construction is completely broken.

In general, offline attacks are considered especially dangerous since an adversary can invest huge computing resources over an extended period of time: in an attack on hash-then-MAC, an attacker could spend months quietly computing on many machines to find a collision on H, without arousing any suspicions.

need both a hash function H and a MAC system I.

say, SHA256 for the hash and CBC-MAC with AES for the MAC.

Prepend the key

an attacker can forge MAC for a message extended original message without knowing a secret mac key.

Append the key

vulnerable to an offline collision-finding attack

Envelope method

needs certain formatting assumptions

k is an l-bit string and M is padded out to a bit string whose length is a multiple of l

Two-key nest

HMAC

the keys k1 and k2 are not independent, but rather, are derived in a somewhat ad hoc way from a single key k.

HMAC0

H(k || x) is secure in the random oracle model, however it is completely insecure if H is a Merkle-Damgard hash.

The problem is that a Merkle-Damgard construction has a very simple, iterative structure which exposes it to “extension attacks”.

While this structure is not a problem from the point of view of collision resistance, it shows that grabbing a hash function “off the shelf” and using it as if it were a random oracle is a dangerous move.

While this construction foils the obvious extension attacks, why should we have any confidence that HMAC0 is safe to use as a general purpose random oracle.

The HMAC0 construction can be proven to be indifferentiable from a random oracle on variable length inputs, if we either model the compression function h itself as a random oracle, or if h is built via Davies-Meyer and we model the underlying block cipher as an ideal cipher.

HKDF

extract stage: key deriviation

t <- HMAC(salt, s)

if s is hard to guess, then t is indistinguishable from random.

when salt is empty, hkdf is the same as HMAC0.

the salt value is independent of the secret s and cannot be manipulated by an adversary.

then, t seems more likely to be indistinguisable from random, without relying on the full power of the random oracle model, but it's still somewhat heuristic.

expand stage: sub-key derivation

https://gyazo.com/ea90868bd3d4c8224e44667c96802a7f

just a simple application of HMAC as a PRF to derive sub-keys.

pbkdf2

https://gyazo.com/13264525593779501debc89841243e4d