Subject: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm

From: "Manger, James H" <[email-masked]>
Date: Wed, 20 Mar 2013 16:57:38 +1100

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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 20 Mar 2013 12:36:10 +0000

Hi James,

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

> 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 :-)

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

> 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

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Wed, 20 Mar 2013 18:18:08 +0000

Hi James and Kenny,

On 3/20/13 8:36 AM, "Paterson, Kenny" <[email-masked]> 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.
>

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.

>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.
>> 
>> 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
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: "Manger, James H" <[email-masked]>
Date: Thu, 21 Mar 2013 10:20:07 +1100

> 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

I suspect HMAC would always be available when AEAD_CBC_HMAC is. Lack of direct access to HMAC cannot motivate this change.

I had been thinking about the structures in JOSE (crypto in a web-friendly format, using JSON, not ASN.1). JOSE supports AEAD operations with a per-message key from a key agreement/exchange/wrap operation. JOSE also supports MACs with a pre-established secret key, but not with a per-message key. JOSE packages MAC functionality together with asymmetric digital signatures. An alternative approach would be to package MAC functionality as a subset of AEAD functionality, in which case AEAD_CBC_HMAC working efficiently as a MAC would be useful. 

[P.S. Another possibility would be to define HMAC as a pseudo-AEAD algorithm that only worked when there was no plaintext, only AAD (ie P_MAX = 0). RFC4543 "GMAC in IPsec ESP and AH" does a vaguely similar trick when defining ENCR_NULL_AUTH_AES_GMAC.]

David’s changes do look small and innocuous so I am very tempted to say "yes please, let’s make those changes". I suspect the right solution for JOSE, though, is to have AEAD and MAC operations as separate explicitly-supported "first-class citizens": separate from asymmetric signatures; and separate from a key agreement/exchange/wrap step. My inclination now is not to the change draft-mcgrew-aead-aes-cbc-hmac-sha2. Thankyou for the considering the idea.

--
James Manger