Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm

["Paterson, Kenny" <[e-mail]>]

Hi James,

Good questions. My personal view in-line. I'll be interested in hearing David's viewpoint.

On 20 Mar 2013, at 05:57, Manger, James H wrote:

> 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.

Indeed, and it's even standardised in various places :-)

> 
> 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?
> 

No, there's no security advantage (that I know of) to having HMAC over "AAD plus random IV" compared to 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".

I see the rationale of reducing overhead. Your proposal would also reduce the randomness requirements of the scheme for this "MAC only" mode. 

But even so I'd prefer not to go down this route because of the potential for confusion and mis-impementation. A single, clean design without too many options feels better in that respect. 

While I don't see any security issues immediately, I'd also be concerned about having a special case that might somehow interact badly with the general case. Do you see anything troubling there? 

Cheers,

Kenny