[Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm

["Manger, James H" <[e-mail]>]

If you pass additional data (AAD), but no plaintext, to the GCM AEAD algorithm you effectively get a MAC algorithm. It even has a name: GMAC.

Presumably it is equally trivial to create a MAC algorithm from any AEAD algorithm.

You can do this with the AEAD_AES_x_CBC_HMAC_SHA_y algorithms in draft-mcgrew-aead-aes-cbc-hmac-sha2-01. However, the output is a 16-byte IV, 16-byte ciphertext (encrypting a block of padding), and the truncated HMAC output. This is 32 bytes more than a straight HMAC of the AAD.

Question 1: Is HMAC over AAD-plus-random-IV better cryptographically than HMAC over just the AAD?


When defining a secure message format a tempting simplification is to only define how to use an AEAD algorithm. Then if a particular message doesn't need confidentiality just put the content into the AAD field and leave the plaintext empty. This approach is less attractive if using an AEAD algorithm in "MAC mode" incurs an unnecessary 32-byte overhead over a dedicated MAC mode.

Question 2: Should draft-mcgrew-aead-aes-cbc-hmac-sha2 add a special case for when the plaintext is empty?
If the answer to Q1 is "No", the special case might be "when the plaintext is empty: set the IV to all zeros; and the output is just the truncated hash (C = T), omitting the IV and ciphertext". Alternatively, the special case might just involve HMAC, with no AES operations.
If the answer to Q1 is "Yes", the special case might be "when the plaintext is empty: the output is C = IV || T, omitting the encrypted padding".


--
James Manger