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

"David McGrew (mcgrew)" <> Tue, 20 November 2012 20:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AD3B221F8817 for <>; Tue, 20 Nov 2012 12:53:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.568
X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iFUK+P1uvH6v for <>; Tue, 20 Nov 2012 12:53:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2B88421F8810 for <>; Tue, 20 Nov 2012 12:53:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=32136; q=dns/txt; s=iport; t=1353444803; x=1354654403; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=xFY7HmrGM7VFLRBFnrDY8hs6RD12q0Or9QD3bGRxB7A=; b=fZayJEVJy9WbsbSRRZGoM8eb1LaXM0TsBgF1Q9ngfdJ59vTfkM+hoHJd 7/cFbhIM83w+t/wGaAIRbimgGGfhNIvuo7oiL0+vgHSBXNMYooo8WTa9y cvdo/0mXfnr5aQ/K7hlfxVkl9HyKKtTZzsCLcsnAky7mmX7kW+h1lRyvT o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AoQFAJLsq1CtJXG+/2dsb2JhbABEgkmtfokGAYkNFnOCHgEBAQQBAQEqQQsSAQgOAwMBAQELFgEGLgsUCQgCBAENBQgBh3IDDwuvD4ZdBYlcjDUag3phA5cajyWCb4FkFx4
X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144547891"
Received: from ([]) by with ESMTP; 20 Nov 2012 20:53:22 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qAKKrMKs011246 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 20 Nov 2012 20:53:22 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 14:53:22 -0600
From: "David McGrew (mcgrew)" <>
To: Tolga Acar <>, 'Russ Housley' <>, 'Mike Jones' <>
Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
Thread-Index: AQHNx2ETlyAzLxb67Eq9P0wOuMXhUQ==
Date: Tue, 20 Nov 2012 20:53:21 +0000
Message-ID: <>
In-Reply-To: <003801cdc5bc$ce464e50$6ad2eaf0$>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_747787E65E3FBD4E93F0EB2F14DB556B0F538AF7xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: 'IRTF CFRG' <>, "" <>
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 20:53:24 -0000

Hi Tolga,

Thanks for the comments, more inline:

From: Tolga Acar <<>>
Date: Sunday, November 18, 2012 1:44 PM
To: 'Russ Housley' <<>>, 'Mike Jones' <<>>
Cc: 'IRTF CFRG' <<>>, "<>" <<>>
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

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.

It makes sense to add a citation, but in Section 4 (Rationale), where PEM and PKCS padding are already mentioned.   The right citation seems to be to add these non-normative references:

   Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers  - RFC 1423
   PKCS #7: Cryptographic Message Syntax v1.5 – RFC 2315
   Cryptographic Message Syntax (CMS) - RFC 5652

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

Your suggestion aims to hide from an attacker whether or not the authentication check passed or failed, by removing the (significant) timing difference in whether decryption is performed or not.  I don't see what security advantage this provides.   In many scenarios an attacker could tell whether or not a message was accepted anyway, by observing that the receiver acted on that message.

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

The draft does consider invalid padding, and takes a conservative in what you send, liberal in what you accept policy.   The sender is required to use PKCS/PEM style padding, but the receiver is only told to consider the final octet of the padding (which is the only octet that matters).   The Step you mention says:

                                                                           If the final octet has
       a value outside that range, then all of the data used in the
       processing of the message is zeroized and discarded, and the AEAD
       decryption operation returns an indication that it failed, and
       the operation halts.

This could be amended by saying that "If the padding string does not have the form described in Step 3, the message MAY be rejected".

I think that the liberal-in-what-you-accept policy is the best option here, but I could be convinced otherwise.   The citations for padding schemes mentioned earlier are silent on this issue.



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