Re: [Cfrg] Security proofs v DH backdoors

Peter Gutmann <> Tue, 01 November 2016 11:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E268129614 for <>; Tue, 1 Nov 2016 04:15:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Status: No, score=-5.697 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.497] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QGRp38w7hSeO for <>; Tue, 1 Nov 2016 04:15:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8928212960F for <>; Tue, 1 Nov 2016 04:15:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1477998946; x=1509534946; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=tO9G/H+aAzcypSnVc7ANcaCbI8AvVlrCd9g38JbUiMg=; b=VO2hsIWbNbInPlbS2e54YxTPoP8qzp7MIFXsWccEqRDCDtBb7GSlo5e5 YLIa9BC91nRNXacgUtvQxAISOhv9FVcOLSZL6n1n+3iHOL3/AK5tEXuWJ mQvYz8yAVqNRNqOS+pOW1t2ntE1u+s2rgILy+uS59G41IbQRoZLgbnfIg 3K0hU8xGSq+4gcCSCUUHIGNyHQIPPMqo9WAe4t0leq8rDCy9IH9/f3334 tgntuNCXBR2xIxgTnNFF2YWnJFh6JUJZwGt+Xv2AJbiRIQ9lx0bQ6/WfK fMG2e9tBalKsPgGWyx6JMbxPpvCL6pu5AFDDniOkZbnecB8uzVuPL8bSp Q==;
X-IronPort-AV: E=Sophos;i="5.31,579,1473076800"; d="scan'208";a="113001244"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES256-SHA; 02 Nov 2016 00:15:43 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 2 Nov 2016 00:15:42 +1300
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Wed, 2 Nov 2016 00:15:42 +1300
From: Peter Gutmann <>
To: Ilari Liusvaara <>
Thread-Topic: [Cfrg] Security proofs v DH backdoors
Thread-Index: AdIuwSDNwRWUIafTQyeYSwlwLZEKKf//K6mAgAHV3UWAAuvMgIADyso2//8zFYCAA/S8Vw==
Date: Tue, 01 Nov 2016 11:15:41 +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: CFRG <>
Subject: Re: [Cfrg] Security proofs v DH backdoors
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: Tue, 01 Nov 2016 11:15:51 -0000

Ilari Liusvaara <> writes:

>Do the devices need to interop with web browsers?

The devices need to talk to each other, and comply with various SCADA
standards (IEC 62351-3 is one that springs to mind, but there are lots of
industry-specific standards and profiles).  What web browsers do ranks some
way down the list of priorities, about the level of an also-ran consideration.

>- If no, then you should be using top-edge TLS or something non-TLS that
>  is competently designed (esp. on constrained environments, as TLS is
>  not very economical there, even with pure-PSK).

This was more or less the same response that some embedded folks got on the
HTTP/2 list when they asked for some very minor changes to make HTTP/2 usable
with embedded, "let them eat HTTP 1.1".  The people driving HTTP/2 basically
said "we don't care about you, we're only designing for the web" (thus the
tongue-in-cheek name of HTTP/2, "HTTP4Google").  This is probably also why
there are approximately, oh, zero embedded folks contributing to the TLS list
(there are several in read-only mode, I'm not aware of anyone contributing

>What libraries would implement that? 

Implement what?