Re: [Cfrg] [TLS] 3DES diediedie

Peter Gutmann <> Thu, 08 September 2016 05:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B955A12B0AD for <>; Wed, 7 Sep 2016 22:53:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.708
X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t9hHC1aWAEWB for <>; Wed, 7 Sep 2016 22:53:37 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6967912B307 for <>; Wed, 7 Sep 2016 22:53:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1473314016; x=1504850016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=aVU9b6wf80/0Pa9fna8MZ+xwE6BoGk8nmiRHzBt809w=; b=UYMUcboEeotT9HKGjudSGL+9RSxaCKsav8Ow5H4DIB0eIiJqBowVKg0n aNTxNP8tpwrKwiuXPlA0O2O5h7f1KJ3to5h1IZ/btJSztFgFqcWIN4dR4 aIpnn25UTipl9BXOFk49pUkCjdaSCz1BfmqYGm24DdmsrVU1iBYAm1bix 0h3v+b9SImBuA5IzgTlrXrxAWps0McEJbCHv3VZJl9XmtqbJjpWs/Iy5R PrynbwbwJo875XVtmus4iCpeQ05nLXILJ5N8pKUazQwdyIJcvadYaJ4UF YfgEdq3B5NzhbCFxUcc/Jiy0JN3y487MKyWIqUbQRc1TRdO6QJPq1TRXp g==;
X-IronPort-AV: E=Sophos;i="5.30,298,1470657600"; d="scan'208";a="105144923"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 08 Sep 2016 17:53:30 +1200
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 8 Sep 2016 17:53:30 +1200
Received: from ([fe80::8081:99e3:dee2:203]) by ([fe80::8081:99e3:dee2:203%14]) with mapi id 15.00.1178.000; Thu, 8 Sep 2016 17:53:30 +1200
From: Peter Gutmann <>
To: Richard Hartmann <>
Thread-Topic: [TLS] [Cfrg] 3DES diediedie
Thread-Index: AQHSCOYwtgYqMp52KUWzQpy/H6FTjaBvGI68
Date: Thu, 8 Sep 2016 05:53:29 +0000
Message-ID: <>
References: <> <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Cfrg] [TLS] 3DES diediedie
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Sep 2016 05:53:40 -0000

Richard Hartmann <> writes:

>Is it correct when I say that the embedded programmers you talked to don't 
>care about any form of DES as they need/must/prefer to do AES, anyway?

The only data point I have is that every time I've tried to disable DES in
a new release (and by DES I mean single DES, not 3DES) I've had a chorus of 
complaints about it vanishing.  Unfortunately I don't have anything more
than that, you only find out about things like this when they break stuff.
Certainly DES still sees a surprising amount of use, and in many cases it's
quite justified, whatever you're protecting is adequately safeguarded with
DES.  For example burglar alarms, if they use real encryption (far too many
use "encryption" that would more accurately be described as data masking),
often use DES, no doubt based on Microchip App Note 583 or freely available
source like despiccable, which runs in 20 bytes of RAM (if your burglar alarm
is advertised as having a "RISC based CPU" then it's probably using a PIC,
having a processor so spartan it can barely add is now a marketing feature if
you use the right name for it).  They'll be using DES forever, because the 
entire environment they operate in runs DES.

>If yes, there's no reason in the embedded world that would prevent a 

See above.  You're not going to get rid of DES.  And, as I've pointed out
earlier, the embedded world won't even know your diediedie exists, and if
it's pointed out to them they'll ignore it.  Alarms, for example, send data
quantities measured in bytes, so some academic attack that would take 500 
million years to acquire the necessary data isn't going to lose anyone any 
sleep.  It's a nice piece of work, but you need to look at what practical 
effect it has on real, deployed systems...