Re: [Cfrg] draft-mcgrew-aead-aes-cbc-hmac-sha2-00: unsafe to optionally hash A's length

[David Wagner <[e-mail]>]

David Wagner  wrote:
>Manger, James H wrote:
>>I am not certain that the way the length of the additional data (A) is
>>optionally hashed is safe.
>>
>>1. Legitimate user sends A and C = S || T, where T = HMAC(A || S || len(A)).
>>
>>2. Attacker intercepts & rearranges the message, sending an empty A' and
>>C' = A || S || len(A) || T.
>>
>>3. Recipient verifies T' = HMAC(S'), since len(A) = 0 = MIN_LEN_A so AL
>>is empty.
>>  T' = HMAC(S') = HMAC(A || S || len(A)) = T
>>The verification passes! Yikes! The recipient now gets garbage from the
>>decryption.
>
>Doesn't the length field take care of this concern?

Oops, I was confused.  I missed the following statement in Section 2.1
of the draft:

   5.  The octet string AL is computed as follows.  If len(A) =
       MIN_LEN_A, then AL is the zero-length string.  Otherwise, it is
       equal to the number of bits in A expressed as a 64-bit unsigned
       integer in network byte order.

Consequently, my email was wrong, and James Manger was perfectly correct.
 Thank you to Santosh Chokhani for pointing out my error.

So I think James Manger has a good point.  Now that I re-read James's
email more carefully, the special case for len(A) = MIN_LEN_A looks
unsafe to me, too.

The rationale does not explain why it is safe to include this special
case.  Some commentary on the rationale (Section 4):

:  The MIN_LEN_A parameter is included
:  so that it is possible to use CBC-HMAC in a way that corresponds to
:  existing uses of CBC and HMAC.  Some existing systems (such as ESP or
:  IEEE 1619.1) make use of those algorithms, but do not include the
:  length of the associated data in the HMAC input.  These systems can
:  be secure because the length of the associated data is fixed, or can
:  be inferred by other means.  The MIN_LEN_A parameter allows the AL
:  field to be zero-length when both the encrypter and the decrypter
:  know the length of the associated data field.  This enables
:  implementations of CBC-HMAC to be compatible with existing systems
:  that do not include the length of A in the HMAC input.

This justifies why the special case provides compatibility, but does
not justify why the special case is secure.

Here's one possible way to handle this that might meet the security and
compatibility needs.  For each of the existing algorithms, you could
create a separate partner algorithm that does not support authenticated
data.  In those algorithms, A and AL are always the empty string.  It is
assumed that the sender and recipient have an out-of-band way to agree on
the algorithm used, with no possibility of confusion and no possibility
for them to get out of sync on this; the security of the scheme relies
upon this assumption.