Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx

Marsh Ray <marsh@extendedsubset.com> Fri, 01 July 2011 20:25 UTC

Return-Path: <marsh@extendedsubset.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 7AE8111E8181 for <tls@ietfa.amsl.com>; Fri, 1 Jul 2011 13:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 ZuQvRAh0nU7k for <tls@ietfa.amsl.com>; Fri, 1 Jul 2011 13:25:27 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id EBB9211E808A for <tls@ietf.org>; Fri, 1 Jul 2011 13:25:26 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1QckHG-000DYR-G7; Fri, 01 Jul 2011 20:25:26 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id AE5C5606E; Fri, 1 Jul 2011 20:25:24 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX188ITbK4aNkFAOHtzaI+7ukM8s7R8v9XWk=
Message-ID: <4E0E2D34.8070005@extendedsubset.com>
Date: Fri, 01 Jul 2011 15:25:24 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
To: mrex@sap.com
References: <201107011958.p61Jwh3a025219@fs4113.wdf.sap.corp>
In-Reply-To: <201107011958.p61Jwh3a025219@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stefan.winter@restena.lu, tls@ietf.org
Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 01 Jul 2011 20:25:27 -0000

On 07/01/2011 02:58 PM, Martin Rex wrote:
> Martin Rex wrote:
>>
>> 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.
>
> Thinking about it, checking whether the first 8x7 bits differ from
> the middle 8x7 bits, and that the middle 8x7 bits differ from the final
> 8x7 bits might have be even more important, because either one being
> equal would cause the 3DES-EDE operation to fold into a single-DES
> operation.  :-o

Doesn't the principle of full key space utilization require us to admit 
that possibility?

As an analogy, TLS uses "separate" encryption keys and MAC secrets in 
the C->S and S->C directions. But it doesn't require an implementation 
to actually verify that they are different. TLS doesn't require checks 
against weak DES keys either which seems even a bit more likely to occur.

One could imagine many ways such a check could go wrong, possibly 
revealing information about the secret material in the process.

- Marsh