Subject: [Cfrg] Fwd: New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt

From: David McGrew <[email-masked]>
Date: Mon, 11 Jun 2012 20:46:01 -0400

Hi,

Kenny and I put together this internet draft defining AEAD algorithms based on AES-CBC and HMAC-SHA.   The main idea behind this work is that current and future standards efforts that use CBC and HMAC can use AEAD, and thus omit unauthenticated encryption altogether.   Your feedback will be welcome.

thanks,

David

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
> Date: June 11, 2012 8:43:34 PM EDT
> To: [email-masked]
> Cc: [email-masked]
> 
> 
> A new version of I-D, draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
> has been successfully submitted by David A. McGrew and posted to the
> IETF repository.
> 
> Filename:	 draft-mcgrew-aead-aes-cbc-hmac-sha2
> Revision:	 00
> Title:		 Authenticated Encryption with AES-CBC and HMAC-SHA
> Creation date:	 2012-06-11
> WG ID:		 Individual Submission
> Number of pages: 23
> URL:             http://www.ietf.org/internet-drafts/draft-mcgrew-aead-aes-cbc-hmac-sha2-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2
> Htmlized:        http://tools.ietf.org/html/submission.filename }}-00
> 
> 
> Abstract:
>   This document specifies algorithms for authenticated encryption with
>   associated data (AEAD) that are based on the composition of the
>   Advanced Encryption Standard (AES) in the Cipher Block Chaining (CBC)
>   mode of operation for encryption, and the HMAC-SHA message
>   authentication code (MAC).
> 
>   These are randomized encryption algorithms, and thus are suitable for
>   use with applications that cannot provide distinct nonces to each
>   invocation of the AEAD encrypt operation.
> 
> 
> 
> 
> The IETF Secretariat

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 13 Jun 2012 12:32:31 +1000

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

---

From: David McGrew <[email-masked]>
Date: Wed, 13 Jun 2012 16:23:21 -0400

Hi James,

thanks for the quick feedback, more inline:

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

> 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 5: Some cases explicitly list PS and AL values, others don't.

Thanks again!

David

---

From: David McGrew <[email-masked]>
Date: Wed, 13 Jun 2012 16:31:25 -0400

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

I should add that the test cases are all consistent with this change - they all have MIN_LEN_A = 0.

David

> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Joachim Strömbergson <[email-masked]>
Date: Thu, 14 Jun 2012 13:25:42 +0200

Aloha!

> I should add that the test cases are all consistent with this change - they all have MIN_LEN_A = 0.

Would it make sense to add a TC for when MIN_LEN!=0?

Yours
JoachimS

-- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================

---

From: David McGrew <[email-masked]>
Date: Fri, 15 Jun 2012 12:00:34 -0400

Hi Joachim,

> Would it make sense to add a TC for when MIN_LEN!=0?

I think it would be best to abandon the option of having a MIN_LEN_A parameter, use David Wagner's suggestion of dealing with cases in which interoperability with existing systems is needed by having a separately defined AEAD algorithm that is not intended for general-purpose use.  

thanks,

David