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.

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

Best,

-          Tolga

From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of Russ
Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; jose@ietf.org
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.

Russ

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: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: cfrg@irtf.org; jose@ietf.org
Subject: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version
01

Hi,

There is a new version of "Authenticated Encryption with AES-CBC and
HMAC-SHA", and I would appreciate your review.   It is online at
<https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu
de_text=1
<https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/?inclu
de_text=1%3e> >   The diff between the current and the previous version is
available at
<http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01
<http://www.ietf.org/rfcdiff?url2=draft-mcgrew-aead-aes-cbc-hmac-sha2-01%3e>
>

This draft has been proposed for use in the JOSE WG
<http://datatracker.ietf.org/wg/jose/
<http://datatracker.ietf.org/wg/jose/%3e> > , 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.  

Thanks,

David

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
http://www.irtf.org/mailman/listinfo/cfrg