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

"Tolga Acar" <> Sun, 18 November 2012 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5C21121F8D68 for <>; Sun, 18 Nov 2012 10:45:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HS_INDEX_PARAM=0.001, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DVbhm6qBrzTS for <>; Sun, 18 Nov 2012 10:45:19 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E88C121F8C13 for <>; Sun, 18 Nov 2012 10:45:18 -0800 (PST)
Received: from [] by with NNFMP; 18 Nov 2012 18:45:14 -0000
Received: from [] by with NNFMP; 18 Nov 2012 18:45:14 -0000
Received: from [] by with NNFMP; 18 Nov 2012 18:45:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=s1024; t=1353264314; bh=Z7wlkYd9cQf3WyVmyh9yA63YrSJtBsAmaSxYWI/O8U8=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:Cc:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Content-Language:thread-index; b=lrE6PQxf+jBUCwHwNCBxrjXgy1oM2nB3K3SvqyfhadJogtN+pwcLi+uRNLlV5eHZ5+YqdKzsc+eKny+iWXzdDcu+vjliGEBpGim/XIzj8EMJog6Ok9jBlLMpauNCzDZ4bi9aDiDXjz9ndHONjgI21c7ucqLEEzihftyIzlkCJ1Y=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: PmyV.QkVM1k2RFGxCoaQleSuk2aiveQ9_ptiX3a1xwiQY5r SfZ6acXvjRiWCvXQpvW48MfP_5P3_K5YWQd2qywgTeSPZZaoks5DOL1N1UOi CgS_pAHtC5Q8TFilvRTSI_OFIVnA17_ZSpSy1pPfJaKjgL.V6xMFJWAagDg0 2YpsmUUPqf.u4hhG9HqDUhArCGfnZNGiGs1tw5E56nNMq0.ku5tj_nuYKxwF CUwRQOBmzo4KPtnU3d.5V7_3SPVgA7MM8lY1XxAIaJaaBdZtIt3d50Nmh0ZA Tn0I8M.sFcm2_bmTz2HomlyDJTYISgmQKQNKM88UelxLhZm0xxreBX8A8Jte VoboLslCICEhgQNvEzEWBqb.l4O.9gD1ak2wjtuLA4RW68Do7nqInrC8wRrB WcXy7W0ms77njb8FmxL.PfTkWHb._WhJeKSxxHqLQa.AFBl1Yj0bH0ZU7qmh yTAbd6H3DMIzduV0-
X-Yahoo-SMTP: 3qJt0gGswBA7ciDNaLLHiPpvI7NLZWkkd3zL
Received: from tolginator (t.acar@ with login) by with SMTP; 18 Nov 2012 10:45:14 -0800 PST
From: Tolga Acar <>
To: 'Russ Housley' <>, 'Mike Jones' <>
References: <> <> <>
In-Reply-To: <>
Date: Sun, 18 Nov 2012 10:44:56 -0800
Message-ID: <003801cdc5bc$ce464e50$6ad2eaf0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0039_01CDC579.C02642A0"
X-Mailer: Microsoft Outlook 14.0
Content-Language: en-us
thread-index: AQH7LcwHg/ezhejU5qFNOX+NYfYUAwFycKfHApQrwMiXdOUeEA==
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: Sun, 18 Nov 2012 18:45:21 -0000

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




There is a new version of "Authenticated Encryption with AES-CBC and
HMAC-SHA", and I would appreciate your review.   It is online at
de_text=1%3e> >   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