Re: [Cfrg] AEAD_AES_x_CBC_HMAC_SHA_y as a MAC algorithm

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

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

> >> Question 2: Should draft-mcgrew-aead-aes-cbc-hmac-sha2 add a special
> >>case for when the plaintext is empty?
> >
> >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

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