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

["Tolga Acar" <[e-mail]>]

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



I realize that is what the theory says up to a negligible probability; but
saying “never even enter decryption stuff” is practically accurate as far as
we know today. I am concerned about not yet existent weaknesses in MAC
functions (and perhaps their underlying hash functions if MAC = HMAC as in
this case), that would open an avenue for a side-channel leakage. Call me
paranoid, and say this is far-fetched.

 

If you go ahead with decryption regardless of a MAC failure, you will return
a failure if decryption fails. This is about MAC succeeding but decryption
failing, which ends up in a failure to be returned anyhow. If both succeeds
when they are not supposed to, then you found that negligible probability
case (or one of them).

 

-          Tolga

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of
David Jacobson
Sent: Monday, November 19, 2012 9:00 PM
To: [e-mail]
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.

   --David

 

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

 

Best,

-          Tolga

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Russ
Housley
Sent: Sunday, November 18, 2012 4:45 AM
To: Mike Jones
Cc: IRTF CFRG; [e-mail]
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: [e-mail] [mailto:[e-mail]] On Behalf Of
David McGrew (mcgrew)
Sent: Monday, November 12, 2012 10:21 AM
To: [e-mail]; [e-mail]
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
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg

 






_______________________________________________
Cfrg mailing list
[e-mail]
http://www.irtf.org/mailman/listinfo/cfrg