Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm

["David McGrew (mcgrew)" <[e-mail]>]

Hi James and Kenny,

On 3/20/13 8:36 AM, "Paterson, Kenny" <[e-mail]> wrote:

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

Agreed.   

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

Yes, good observation.

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

Agreed.

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

I recognize both the motivation for reducing bandwidth and the concern
about special cases that might inadvertently cause trouble.

If there are implementations that would use AEAD_CBC_HMAC as a MAC, then I
think it makes sense to do the bandwidth optimization, *if* we can
convince ourselves that there is no potential for badness on the
decryption side.  It seems as though the change would come in Steps 2 and
4 of Section 2.2 "Decryption", which would change to something like:

   2. If C contains exactly T_LEN octets, then S is the zero-length
      String.  Otherwise, ...

...

   4. If S is the zero-length string, then P is set to the zero-length
string.
      Otherwise, ...


At Step 2 of Section 2.1 "Encryption", we would need to say "If P contains
exactly zero octets, then S is the zero-length string; skip to step 5."


It looks innocuous, but deserves more analysis I think.  My inclination is
that we should only add this if there are plans to use the algorithm as a
MAC.  Are there scenarios in which AEAD_CBC_HMAC would be available, but
the underlying HMAC would not? I can see value in minimizing the number of
entry points to a crypto implementation, but on the other hand, HMAC is
already broadly available.

David


>
>Cheers,
>
>Kenny
>_______________________________________________
>Cfrg mailing list
>[e-mail]
>http://www.irtf.org/mailman/listinfo/cfrg