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

"Tolga Acar" <t.acar@att.net> Tue, 20 November 2012 06:27 UTC

Return-Path: <t.acar@att.net>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9CFD21F8D2B for <cfrg@ietfa.amsl.com>; Mon, 19 Nov 2012 22:27:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OirF74k8+M8q for <cfrg@ietfa.amsl.com>; Mon, 19 Nov 2012 22:26:59 -0800 (PST)
Received: from nm3-vm0.access.bullet.mail.sp2.yahoo.com (nm3-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.108]) by ietfa.amsl.com (Postfix) with ESMTP id 89CBE21F8B00 for <cfrg@irtf.org>; Mon, 19 Nov 2012 22:26:59 -0800 (PST)
Received: from [98.139.44.100] by nm3.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000
Received: from [67.195.14.111] by tm5.access.bullet.mail.sp2.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000
Received: from [127.0.0.1] by smtp108.sbc.mail.gq1.yahoo.com with NNFMP; 20 Nov 2012 06:26:56 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1353392816; bh=ncN+GYx3oNTWEA3KNRsM+KTw2uYucI1VGR7dke0QHIU=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language; b=BiyR2nAhOXkCm1Okwcv6aVHLvrUfScRpE15ofAnE6D/xNu7LRRUbOCrO7x40hVL3V8OoUthI+tp/ZygnLOFZfoZbL41BDrrQ/OGg8XITuvyusBJkexDivsK4w3nCLHnMESIGPJDAgNQji9hMsNptHBYzFTqHKXmqQx8NOjyw6Vw=
X-Yahoo-Newman-Id: 426450.97242.bm@smtp108.sbc.mail.gq1.yahoo.com
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: fa9DmUoVM1myPo.5psJEzJQeeh.nGEiP93751a5MDVCeMBY Sf7m.rMjoWZ80YASZRuQslkw_2lBgtGU7FyHxWP7Ru6JMYKoRwwhjxn1oDU9 ki.gcq6Tfqe.7Sc6PFVhUppK8zzwmMIDrHH88QsvSg27MNUzbNvH3SXBRAl. LDmogiOeX07UuGAfSxr6VLW93ihAAhWo_e64qlX7htCN0.tZK9ZsrKsAE8gE qhfsdDxzl3wlZTnFYAR93XoXKNnfkAFKGqqgi7GjVlJE6iWdBCVScO01ZZtV R.TTwNtlFPAjcBu_58N6zBWzcQ1vgtXAHM9xlX6LANkUoCsvvo9Ez2dQOeGJ EybSQ8AS.Wnz0mT7jz13WlvlAlo6mVQWPK9g0kw3am7EC0o0LR_DYXlDLJxy 2.IPyjqKSrp5N0eJ_zyVXQ0u8XUOm76_yxmG.Ozfyql2gNTlzs_q7_eCJ1dA URUZjbOguGWa3nII-
X-Yahoo-SMTP: 3qJt0gGswBA7ciDNaLLHiPpvI7NLZWkkd3zL
Received: from tolginator (t.acar@174.61.228.6 with login) by smtp108.sbc.mail.gq1.yahoo.com with SMTP; 19 Nov 2012 22:26:56 -0800 PST
From: "Tolga Acar" <t.acar@att.net>
To: "'David Jacobson'" <dmjacobson@sbcglobal.net>, <cfrg@irtf.org>
References: <747787E65E3FBD4E93F0EB2F14DB556B0F50A96C@xmb-rcd-x04.cisco.com> <4E1F6AAD24975D4BA5B1680429673943668B026C@TK5EX14MBXC283.redmond.corp.microsoft.com> <FE2BC73F-41FA-4B5B-900C-117749CEEBAC@vigilsec.com> <003801cdc5bc$ce464e50$6ad2eaf0$@att.net> <50AB0E38.9050700@sbcglobal.net>
In-Reply-To: <50AB0E38.9050700@sbcglobal.net>
Date: Mon, 19 Nov 2012 22:26:55 -0800
Message-ID: <00b001cdc6e8$09a82820$1cf87860$@att.net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B1_01CDC6A4.FB8A6660"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH7LcwHg/ezhejU5qFNOX+NYfYUAwFycKfHApQrwMgDFiARxQIEuJ6nl05m/MA=
Content-Language: en-us
Subject: Re: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Nov 2012 06:27:03 -0000

Ø  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: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
David Jacobson
Sent: Monday, November 19, 2012 9:00 PM
To: cfrg@irtf.org
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: 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

 






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