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

[David Wagner <[e-mail]>]

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?

The recipient will try to verify whether T' = HMAC(A' || S' || len(A')),
I presume.  [not T' = HMAC(S'), as you wrote]

Note that

  HMAC(A' || S' || len(A'))
    = HMAC(A' || S' || 0)
    = HMAC(S' || 0)
    = HMAC(A || S || len(A) || 0)

which is not the same as HMAC(A || S || len(A)), i.e., it is not the
same as T'.  So the recipient's MAC check fail, and the recipient will
reject the message.

In short, the format looks fine to me.  Have I misunderstood something
somewhere?