Re: [TLS] [Cfrg] 3DES diediedie

Peter Gutmann <> Sat, 27 August 2016 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93C5312B046 for <>; Sat, 27 Aug 2016 05:21:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Status: No, score=-4.748 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=-0.548] 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 BYvB76lPLAYS for <>; Sat, 27 Aug 2016 05:21:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6D1312B00D for <>; Sat, 27 Aug 2016 05:21:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1472300473; x=1503836473; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=+H9EosnlMnTK+2oM2IFLwkGLFc05wjKA2A7sWFWU3Sk=; b=yFHWCTSwkg6Pw477EN1W8+PuhMr2WCSIKXwxt3DU3dnxirKCMjqUuCNe YrcOtPd1LoNL5NXlZNCzthXeMqxCGy7wakTm2B+g33igzLyhMimllU/rx KgGG/d3S1b+iJMyc5mMhRWB45g02W+tMsTlyYse8xX7e0w+uzgyYmhhgN KyF8opfyDMoBEHSESBESial93b+8gCr+4nYUybyf4S5MUFo6SNgXtxmei LygNSAz0DWgIsJigPFOGqa/oawS3HhV6NKVVvxAH8olkTpO10PW9t5M12 /89l3FWmBX/l32zMr4J3oE4Z4hHuPZU+lfrp/VVylN2ieCo0LfHodd5cV Q==;
X-IronPort-AV: E=Sophos;i="5.28,586,1464609600"; d="scan'208";a="103684428"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 28 Aug 2016 00:21:10 +1200
Received: from ([]) by ([]) with mapi id 14.03.0266.001; Sun, 28 Aug 2016 00:21:11 +1200
From: Peter Gutmann <>
To: "David McGrew (mcgrew)" <>, Tony Arcieri <>, "<>" <>, "" <>
Thread-Topic: [Cfrg] 3DES diediedie
Thread-Index: AQHR/8MKtrFGWEVZoU+YIDla8GEE7aBcuoQ1
Date: Sat, 27 Aug 2016 12:21:09 +0000
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
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: Sat, 27 Aug 2016 12:21:14 -0000

David McGrew (mcgrew) <> writes:

>Most of the lightweight “designed for IoT” block ciphers have a 64 bit block
>size (and sometimes even smaller); see for instance Table 1.1 of
> So perhaps what the Internet needs here
>is sound guidance on how to use 64-bit block ciphers.   Best practices here
>include both mandatory rekeying well below the birthday bound and/or the use
>of secure beyond the birthday bound modes of operation such as Iwata’s CENC.

IoT devices are, pretty much by default, insecure.  And I mean, really, really
insecure, I've heard phrases like "hack like it's 199x" a number of times
during talks on all the holes people have found in these things.  In addition,
the reason why devs are using lightweight ciphers in IoT devices is because
they know that their device can't use anything more powerful, in the same way
they they know that a strcpy() into a ten-byte fixed-size buffer is a good way
to decode network packets.

Looking at it from the other side, your typical IoT device will be sending,
for example, a 12-byte message every 15 minutes, meaning it'll take, if my
calculations are right, just under two million years to collect the 785GB of
data required to perform the attack.

So you've got something where the devices aren't vulnerable to the problem
(and nor, in any practical case, is anything else), for which the devs
involved won't even know that any guidance on the situation exists, and for
which, if anyone really wants to attack them, they can use any of the dozens
of insecure-by-design holes that are present in the device to own the whole
thing, at which point what you do with your crypto becomes meaningless.

So what you're proposing is essentially a non-solution to a non-problem...
still, if you feel like writing the memo for it, don't let me stand in your