Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)

"Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk> Wed, 04 December 2013 09:21 UTC

Return-Path: <Kenny.Paterson@rhul.ac.uk>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD1F1ADFD0 for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 01:21:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni-RW_y15jKw for <tls@ietfa.amsl.com>; Wed, 4 Dec 2013 01:20:58 -0800 (PST)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id C879A1AE21C for <tls@ietf.org>; Wed, 4 Dec 2013 01:20:57 -0800 (PST)
Received: from mail84-va3-R.bigfish.com (10.7.14.235) by VA3EHSOBE012.bigfish.com (10.7.40.62) with Microsoft SMTP Server id 14.1.225.22; Wed, 4 Dec 2013 09:20:54 +0000
Received: from mail84-va3 (localhost [127.0.0.1]) by mail84-va3-R.bigfish.com (Postfix) with ESMTP id 8DC8E4E01B3; Wed, 4 Dec 2013 09:20:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.249.149; KIP:(null); UIP:(null); IPV:NLI; H:AM2PRD0311HT005.eurprd03.prod.outlook.com; RD:none; EFVD:NLI
X-SpamScore: -7
X-BigFish: PS-7(zzbb2dI98dI936eI1432Izz1f42h208ch1ee6h1de0h1d18h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah1fc6hzz1de098h17326ah8275bh1de097h186068h5eeeKz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1fe8h1ff5h209eh2216h22d0h2336h1155h)
Received-SPF: pass (mail84-va3: domain of rhul.ac.uk designates 157.56.249.149 as permitted sender) client-ip=157.56.249.149; envelope-from=Kenny.Paterson@rhul.ac.uk; helo=AM2PRD0311HT005.eurprd03.prod.outlook.com ; .outlook.com ;
X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(243025003)(51704005)(199002)(189002)(24454002)(377424004)(479174003)(15202345003)(65816001)(80022001)(66066001)(74706001)(81342001)(77982001)(59766001)(74366001)(56776001)(69226001)(76796001)(63696002)(90146001)(54316002)(81542001)(76786001)(56816005)(79102001)(85852002)(53806001)(54356001)(46102001)(51856001)(87266001)(81686001)(76482001)(83322001)(19580405001)(19580395003)(83506001)(31966008)(76176001)(85306002)(15975445006)(80976001)(47446002)(74662001)(74482001)(74502001)(49866001)(47736001)(4396001)(36756003)(47976001)(50986001)(74876001)(2656002)(87936001)(81816001)(83072001); DIR:OUT; SFP:; SCL:1; SRVR:DBXPR03MB382; H:DBXPR03MB383.eurprd03.prod.outlook.com; CLIP:80.42.211.100; FPR:; RD:InfoNoRecords; A:1; MX:1; LANG:en;
Received: from mail84-va3 (localhost.localdomain [127.0.0.1]) by mail84-va3 (MessageSwitch) id 1386148852643338_21999; Wed, 4 Dec 2013 09:20:52 +0000 (UTC)
Received: from VA3EHSMHS017.bigfish.com (unknown [10.7.14.247]) by mail84-va3.bigfish.com (Postfix) with ESMTP id 8DB712C00A5; Wed, 4 Dec 2013 09:20:52 +0000 (UTC)
Received: from AM2PRD0311HT005.eurprd03.prod.outlook.com (157.56.249.149) by VA3EHSMHS017.bigfish.com (10.7.99.27) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 4 Dec 2013 09:20:52 +0000
Received: from DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) by AM2PRD0311HT005.eurprd03.prod.outlook.com (10.255.162.40) with Microsoft SMTP Server (TLS) id 14.16.383.1; Wed, 4 Dec 2013 09:20:44 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB382.eurprd03.prod.outlook.com (10.141.10.12) with Microsoft SMTP Server (TLS) id 15.0.837.10; Wed, 4 Dec 2013 09:20:42 +0000
Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.0837.004; Wed, 4 Dec 2013 09:20:42 +0000
From: "Paterson, Kenny" <Kenny.Paterson@rhul.ac.uk>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Thread-Topic: [TLS] Encrypt-then-MAC again (was Re: padding bug)
Thread-Index: AQHO7R77H2f5vAeCGkOkJhCJPGzqVZo8bsWAgAA2+ACAABbXAIAAHPYAgAAhpACAAPI6AIAAG7aAgAWtiYCAABNLAA==
Date: Wed, 4 Dec 2013 09:20:42 +0000
Message-ID: <CEC4A246.10D91%kenny.paterson@rhul.ac.uk>
In-Reply-To: <1386144695.2047.30.camel@aspire.lan>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [80.42.211.100]
x-forefront-prvs: 0050CEFE70
Content-Type: text/plain; charset="us-ascii"
Content-ID: <23B0B38CE41DCF45B492F6D0C680094A@eurprd03.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: rhul.ac.uk
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Dec 2013 09:21:00 -0000

Nikos,

On 04/12/2013 08:11, "Nikos Mavrogiannopoulos" <nmav@redhat.com> wrote:

<snippage>

>On Sat, 2013-11-30 at 17:29 +0000, Paterson, Kenny wrote:
>
>> 2. It assumes the MAC output size is the same as the block cipher's
>>block
>> size.
>
>That I hadn't notice, and if it is not fixable, it is indeed a strong
>counter-argument against pad-mac-then-encrypt.
>
>> On the plus side, and perhaps this is what you were referring to, Hugo's
>> analysis works just fine for stream-cipher based ciphersuites (as long
>>as
>> the stream cipher is good - so not RC4 then!). The Asiacrypt 2011 paper
>> can be seen as extending his analysis to handle the actual construction
>> used in TLS's CBC-mode ciphersuites, but with the important, necessary,
>> and difficult-to-achieve proviso concerning uniformity of errors.
>
>So as I understand your proof fixes the point (2), that you mentioned
>above?

It should. But, to our continuing embarrassment, the proof is not yet in
the public domain - the published version of the paper does not include
it, because of page limits, and we never got the full version into a shape
that we are happy with. We have more motivation than ever to finish it.

I also believe the Phil Rogaway and co-authors have been examining MtE
versus EtM recently, and should have some new results that give additional
support to MtE provided the encryption scheme satisfies certain natural
properties. I'll see if I can get Phil or his co-authors to post a summary
here, but if you want an advance preview, there's this:

http://2013.diac.cr.yp.to/slides/rogaway.pdf


particularly slides 7 and 8 (but notice the conditions on the encryption
scheme on slide 8).

Cheers

Kenny