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

[David McGrew <[e-mail]>]

Hi James,

thanks for the quick feedback, more inline:

On Jun 12, 2012, at 10:32 PM, Manger, James H wrote:

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

Agreed.   MIN_LEN_A was an under analyzed suggestion of mine, intended as a way to enable these AEAD algorithms to interoperate with some existing implementations of CBC and HMAC.   It is not clear that the interoperability I was going for is even important, and as you point out, the particular way that the length of A was included doesn't work.  Change is clearly needed.   I suggest that Step 5 should read: "The octet string AL is equal to the number of bits in A expressed as a 64-bit unsigned integer in network byte order."

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

Agreed on all points.

> 
> Section 4: Stray " at end of Rationale.
> 
> Section 5: Some cases explicitly list PS and AL values, others don't.

Thanks again!

David

> 
> --
> James Manger