Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx

Marsh Ray <> Fri, 01 July 2011 20:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7AE8111E8181 for <>; Fri, 1 Jul 2011 13:25:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZuQvRAh0nU7k for <>; Fri, 1 Jul 2011 13:25:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBB9211E808A for <>; Fri, 1 Jul 2011 13:25:26 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1QckHG-000DYR-G7; Fri, 01 Jul 2011 20:25:26 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id AE5C5606E; Fri, 1 Jul 2011 20:25:24 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX188ITbK4aNkFAOHtzaI+7ukM8s7R8v9XWk=
Message-ID: <>
Date: Fri, 01 Jul 2011 15:25:24 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110424 Thunderbird/3.1.10
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Question about TLS_RSA_WITH_3DES_EDE_CBC_SHAx
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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