Subject: [Cfrg] Designing a CMAC kdf

From: Robert Moskowitz <[email-masked]>
Date: Tue, 18 May 2010 12:21:04 -0400

I HOPE I am getting somewhere positive.

I have been studing hkdf, NIST 800-108, and RFC 4615.

I am mashing them together a bit but basically I see a CMAC extract and 
expand kdf function just like in hkdf.  Even if we ASSuME that the key 
as randomly uniformly distributed (requirement for a CMAC kdf per 
kdf-uses, there are still two points where an Extract phase is of value:

Adding a SALT to the kdf.

This could be important if the key is provided by only one party, to get 
randomness from the second party.  Of course the SALT itself could 
contain randomness from both parties.

Getting a key for the Expand phase that matches the block size.

Perhaps the provided key does not match the block size for CMAC.  The 
Extract phase could produce the proper length key.

The Extract phase would follow the first stage in RFC 4615:

K := AES-CMAC(0^128, VK, VKlen)

But it needs a salt, so taking from hkdf

PRK := AES-CMAC(0^128, VK|salt, VKlen)

Though something nudges the back of my mind that there is an old problem 
with VK|salt

 From here the Expand would be closely aligned with hkdf and the counter 
mode model in 800-108:

    T(0) = empty string (zero length)
    T(1) = CMAC(PRK, T(0) | info | 0x01)
    T(2) = CMAC(PRK, T(1) | info | 0x02)
    T(3) = CMAC(PRK, T(2) | info | 0x03)

Does this all make sense?  Can someone here do it better?  I do see a 
couple messages on hkdf claiming that they could build a CMAC kdf...