Re: [TLS] Encrypt-then-MAC again (was Re: padding bug) (Martin Rex) Mon, 02 December 2013 23:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E6C4E1ADF9B for <>; Mon, 2 Dec 2013 15:08:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tx7X08LEDCiN for <>; Mon, 2 Dec 2013 15:08:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EBB4D1ADF9D for <>; Mon, 2 Dec 2013 15:08:02 -0800 (PST)
Received: from by (26) with ESMTP id rB2N7wf6029006 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Dec 2013 00:07:58 +0100 (MET)
In-Reply-To: <1385826600.11639.25.camel@aspire.lan>
To: Nikos Mavrogiannopoulos <>
Date: Tue, 3 Dec 2013 00:07:58 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Subject: Re: [TLS] Encrypt-then-MAC again (was Re: padding bug)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 02 Dec 2013 23:08:06 -0000

Nikos Mavrogiannopoulos wrote:
> On Fri, 2013-11-29 at 17:23 -0800, Watson Ladd wrote:
> > > Contrary to popular opinion on this list AtE is a standard way of
> > > operation with no flaws known unless used with an unauthenticated pad
> > > (as in TLS). When SSL 3.0 was designed AtE was believed to be the
> > > conservative approach comparing to EtA.
> > The passive voice is doing a lot of work here. Bellare and Namparah
> > showed that EtA is generically secure,
> > AtE isn't. Rogaway sent out an email in 1995 pleading for EtA in TLS.
> > "no flaws known"!="proved to be secure"
> Proven to be secure doesn't mean that attacks don't exist. The TLS
> padding scheme was proven to be secure prior to be broken; ironically by
> the same person who made the proof. Attacks work by playing outside the
> requirements of the proof.
> Nevertheless, there is much more recent work on EtA vs AtE, that
> actually proves AtE secure (not "generically" as you pose, you just need
> a decent cipher). You may check "The order of encryption and
> authentication for protecting communications (or: How secure is SSL?)".
> There are even newer papers than that, it is just this that came to
> mind.

Very important observation.

Peter's proposal changes AtE to EtA, but does not currently address
the predictable IV for SSLv3 & TLSv1.0.  As it turns out, EtA will
not protect from BEAST, because it is "generically" secure only against
decryption oracles.  BEAST was exploiting an _encryption_ oracle.