Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA

Martin Rex <mrex@sap.com> Fri, 01 July 2011 19:46 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 2154D9E8022 for <tls@ietfa.amsl.com>; Fri, 1 Jul 2011 12:46:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.144
X-Spam-Level:
X-Spam-Status: No, score=-10.144 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 bq2CeoOg3oA3 for <tls@ietfa.amsl.com>; Fri, 1 Jul 2011 12:46:28 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6259C9E8024 for <tls@ietf.org>; Fri, 1 Jul 2011 12:46:28 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p61JkKm7001941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 1 Jul 2011 21:46:25 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107011946.p61JkK5m024466@fs4113.wdf.sap.corp>
To: agl@google.com (Adam Langley)
Date: Fri, 1 Jul 2011 21:46:20 +0200 (MEST)
In-Reply-To: <CAL9PXLwpwHZM9mkYJ4cm_KbgEokm1J9xyJbvknRWJ+so3f1Nqw@mail.gmail.com> from "Adam Langley" at Jul 1, 11 09:20:06 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: stefan.winter@restena.lu, tls@ietf.org
Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHA
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: Fri, 01 Jul 2011 19:46:29 -0000

Adam Langley wrote:
> 
> Stefan Winter <stefan.winter@restena.lu> wrote:
> >
> > I'm not sure whether TLS_RSA_WITH_3DES_EDE_CBC_SHA is a two-key
> > or a three-key 3DES algorithm. This condition would be the only
> > one that could downgrade the I-D in question from
> > "unconditionally compliant" to "conditionally compliant".
> 
> I believe it's the 3-key algorithm. RFC 5246, App B covers this:
> 
> "DES can also be operated in a mode [3DES] where three independent
> keys and three encryptions are used for each block of data; this uses
> 168 bits of key (24 bytes in the TLS key generation method) and
> provides the equivalent of 112 bits of security."

see also  http://tools.ietf.org/html/rfc2246#page-21

It is a probabilistic 3-key DES-EDE (encryption-decryption-encryption),
meaning that the algotihm is treated as a block cipher with a
keysize of 24 octets, blocksize of 8 octets and cbc-ivsize of 8 octets
(distinct keying material for direction client->server and server->client).

The first 8x7 bits (sans parity) differ from the final 8x7 bits of the key
on probabilistic grounds, there are no algorithmic provisions to ensure
this, and neither are there algorithmic provisions to ensure that
none of the 3 single-DES subkeys are weak DES keys.
 
(you're certainly better of with AES128-CBC, in particular because it
 is significantly faster--on x86 and x86_64  AES128-CBC has 6x higher
 data encryption rate than 3DES-EDE for optimized software-implementations.)


-Martin