Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

"Igoe, Kevin M." <> Tue, 20 November 2012 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA54621F872A for <>; Tue, 20 Nov 2012 09:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NI7WIIF6MMmX for <>; Tue, 20 Nov 2012 09:37:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 028CF21F86C6 for <>; Tue, 20 Nov 2012 09:37:03 -0800 (PST)
X-TM-IMSS-Message-ID: <>
Received: from ([]) by ([]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 0d7f18b40000d934 ; Tue, 20 Nov 2012 08:13:50 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 20 Nov 2012 08:10:21 -0500
Received: from ([]) by ([]) with mapi id 14.01.0289.001; Tue, 20 Nov 2012 08:10:20 -0500
From: "Igoe, Kevin M." <>
To: 'David Jacobson' <>, "" <>
Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
Thread-Index: AQHNxtvg5dRmH42ImUCxpzeefAod4Zfyrl3w
Date: Tue, 20 Nov 2012 13:10:19 +0000
Message-ID: <>
References: <> <> <> <003801cdc5bc$ce464e50$6ad2eaf0$> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA3AFE5D17MSMRGH1UEA03cor_"
MIME-Version: 1.0
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Nov 2012 17:37:10 -0000

I'll agree with David's position, but for a slightly different reason.  A packet with a bad MAC may mean
the decrypted PT is malicious.  Not decrypting CT with a bad MAC cryptographically enforces the policy
that questionable packets MUST NOT be released to the receiving user/processes.

Misuse of AES-CBC-HMAC-SHA (we really need a shorter name) by a well intentioned application programmer
is, in my opinion, the larger risk.  By never even decrypting questionable CT there is no chance the programmers
will, with the best of intentions,   make a security critical mistake by acting upon malicious PT.

From: [] On Behalf Of David Jacobson
Sent: Tuesday, November 20, 2012 12:00 AM
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

I think I'd argue the other way on continuing on on when the MAC fails.

One big advantage of encrypt-then-MAC is that the receiving end does MACverify-then-decrypt.  If the message has been tampered with, the MAC fails to verify and we never even enter the decryption stuff, thus there is never even the possibility of padding oracles, timing attacks, etc.  If you go ahead with the decryption, you risk revealing something.


On 11/18/2012 10:44 AM, Tolga Acar wrote:
Quick feedback on the draft

*         Page 5, item 3, padding string PS. Please \cite PKCS#5 so it is clear this is not new, but a reuse of an existing padding scheme.

*         Section 2.2, step 3. When MAC verification fails, the draft recommends halting the operation before CBC decryption. We have seen timing and error-code based attacks against TLS' MAC-then-Encrypt scheme. I realize that the draft is prescribing E-t-M. Nonetheless, considering a potential flaw in HMAC-SHA2 series (I don't know of any, but ...), I'd suggest not halting the operation even after MAC check fails, but continuing on to CBC decryption, and then returning an error that doesn't distinguish between a MAC and a decryption (pad check) error. Yes, this would consume more CPU cycles only to waste them *under an attack*, which is not necessarily bad.

*         Section 2.2, step 5. Unspecified error case of invalid padding (link to my comment above).


-          Tolga

From:<> [] On Behalf Of Russ Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

Have you looked at the algorithm in RFC 6476?  While the discussion is CMS-specific, the algorithm could be used with another syntax.


On Nov 12, 2012, at 1:55 PM, Mike Jones wrote:

As background, if there was a version of this spec that did not assume that the parameters would be concatenated together in a specific way, but left them as independent inputs and outputs, as AES GCM and AES CTR do, it would be a better match for JOSE's use case.

                                                            -- Mike

From:<> [] On Behalf Of David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01


There is a new version of "Authenticated Encryption with AES-CBC and HMAC-SHA", and I would appreciate your review.   It is online at <><>   The diff between the current and the previous version is available at <><>

This draft has been proposed for use in the JOSE WG <><> , where its adoption would allow the working group to omit "raw" unauthenticated encryption, e.g. AES-CBC, and only include authenticated encryption.   Thus I am asking for your help in making

John Foley generated test cases that correspond to the current version of the draft, but I didn't include these in the draft because I did not yet get confirmation from a second independent implementation.   With hope, there will not be any need for any normative changes, and I will include these after I get confirmation.


Cfrg mailing list<>


Cfrg mailing list<>