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

mrex@sap.com (Martin Rex) Thu, 14 November 2013 16:21 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2E321E8056 for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:21:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.186
X-Spam-Level:
X-Spam-Status: No, score=-10.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrCWqWPJyqVM for <tls@ietfa.amsl.com>; Thu, 14 Nov 2013 08:21:49 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 9930D11E80E3 for <tls@ietf.org>; Thu, 14 Nov 2013 08:21:49 -0800 (PST)
Received: from mail06.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id rAEGLhMD027215 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 14 Nov 2013 17:21:43 +0100 (MET)
In-Reply-To: <CA+BZK2oDFw7dQfrf-GqXRnb6aTtEGek4j5gbBxmow6C7Wj60XA@mail.gmail.com>
To: Ralf Skyper Kaiser <skyper@thc.org>
Date: Thu, 14 Nov 2013 17:21:43 +0100
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: <20131114162143.4719D1AA90@ld9781.wdf.sap.corp>
From: mrex@sap.com
X-SAP: out
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.12
Precedence: list
Reply-To: mrex@sap.com
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: Thu, 14 Nov 2013 16:21:54 -0000

Ralf Skyper Kaiser wrote:
>
> With EtA you need to trust the MAC. With AtE you need to trust the cipher
> _and_ the MAC.

I believe you're confused.

The MAC provides integrity protection, the Encryption provides
confidentiality.  The quality of the MAC has exactly Zero impact
on the confidentiality provided by the Encryption.

For EtA, the characteristics&quality of the Cipher do not affect
(and therefore can not improve) the quality of the MAC scheme
at all.

For AtE, the characteristics&quality of the Cipher additionally
strengthen the quality of the MAC scheme, so weaknesses in the MAC
scheme do not immediately translate into a vulnerability.

Look at AES-GCM (NIST SP800-38D).  They use an efficient keyed has GHASH,
that does not have cryptographic hash properties (2nd paragraph Page 10):

  http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf

  GHASH is a keyed hash function but not, on its own, a cryptographic
  hash function. This Recommendation only approves GHASH for use within
  the context of GCM.

The use of GHASH without cryptographic protection would not be safe.


-Martin