Re: [TLS] [Cfrg] 3DES diediedie

Derek Atkins <> Thu, 08 September 2016 15:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C178D12B0DE for <>; Thu, 8 Sep 2016 08:21:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7zGYOQvCQPHy for <>; Thu, 8 Sep 2016 08:21:04 -0700 (PDT)
Received: from (MAIL2.IHTFP.ORG []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 850CB12B032 for <>; Thu, 8 Sep 2016 08:21:04 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A4D7E2046; Thu, 8 Sep 2016 11:21:03 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-maia, port 10024) with ESMTP id 09760-08; Thu, 8 Sep 2016 11:21:01 -0400 (EDT)
Received: from (unknown [IPv6:2001:470:e448:2:ea2a:eaff:fe7d:235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "IHTFP Consulting Certification Authority" (verified OK)) by (Postfix) with ESMTPS id 93183E2043; Thu, 8 Sep 2016 11:21:01 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1473348061; bh=VvcQf2SkUUIHDtBrcFiEhJLmu6uquELSgayNFPoY8nU=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=UzHaIiaYSLKz4CWBHyqBwtxCUPFCcywU0+DbR1IgOxrkpfs9fyFqb0on7cCmNppac B3nciuWiR2xvvkQHOygNTS8m/KncH1V7/qnLoTcAua2qsEmUZgRisyT6cvPFF30rDB 7N2GXFFLwaAiYsccn4TlgQnRkFyWP7+V91YIRBHE=
Received: (from warlord@localhost) by (8.15.2/8.14.8/Submit) id u88FL0ne009856; Thu, 8 Sep 2016 11:21:00 -0400
From: Derek Atkins <>
To: Peter Gutmann <>
References: <> <> <> <> <> <> <>
Date: Thu, 08 Sep 2016 11:21:00 -0400
In-Reply-To: <> (Peter Gutmann's message of "Thu, 8 Sep 2016 05:53:29 +0000")
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [TLS] [Cfrg] 3DES diediedie
X-Mailman-Version: 2.1.17
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: Thu, 08 Sep 2016 15:21:09 -0000

Peter Gutmann <> writes:

> 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...


> Peter.


       Derek Atkins                 617-623-3745   
       Computer and Internet Security Consultant