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

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

RE: Authenticated Encryption with AES-CBC and HMAC-SHA

Great document.

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.
The attack might only work if len(A) mod 128 = 64, but that is not hard enough.


An attack can also work if the legitimate user sends an empty A.
1. Legitimate user sends empty A and C = S || T, where T = HMAC(S).

2. Attacker splits S into 3 parts, S = S1 || S2 || S3, choosing len(S3) = 64 and len(S1) = S3. The attacker sends A' = S1 and C' = S2 || T.

3. Recipient's verification works! Yikes!
  T' = HMAC(A' || S' || len(A)) = HMAC(S1 || S2 || S3) = HMAC(S) = T
The recipient now gets garbage from the decryption.
The attack might only work if the last 64 bits are a small enough integer (and equal 64 mod 128), but that is not hard enough.




Typos:

Section 2.1: The last padding string (PS) in step 3 should be 1010…, not 0F0F…, as can be seen in the P_9 line in the section 5.1 test case. Change it to:

  PS = 10101010101010101010101010101010, if len(P) mod 128 = 0.

Section 2.2: Decryption step 3 should refer to encryption "steps 5 and 6", not just to "step 5".

Section 3: A random IV should have min-entropy within 1 bit of the block size (128-bits), not within 1 bit of the key length (which is longer than the IV for AES-192 and AES-256 algorithms).

Section 4: Stray " at end of Rationale.

Section 5: Some cases explicitly list PS and AL values, others don't.

--
James Manger