Re: [Cfrg] Security proofs v DH backdoors

Peter Gutmann <> Fri, 28 October 2016 09:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5D866129A1E for <>; Fri, 28 Oct 2016 02:58:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.631
X-Spam-Status: No, score=-4.631 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.431] 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 rct3whfyDHpj for <>; Fri, 28 Oct 2016 02:58:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7526A1299F2 for <>; Fri, 28 Oct 2016 02:58:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=mail; t=1477648699; x=1509184699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8pWmZWG+KoYrjo7goODhHNd5Ibj/TYqObKIkc3Qn300=; b=A0qIHuj/DjnMgFM5T7vtkaaBN9JL2oI2vAy2qkwobQaN9dZF0hcBeR0l nf3nyGYiFVfPV9BIp5G69DjDz5/ROWYlJq2CArhqSu/IGRAqRd91irykC rx9owCK63wVSEbkPSl9m8RzROpmEyrFAoIS2dOu5nPZWruUfNpHrwt3ca SMi2ypnBzb3oWRZlRUz8hHbV3lZbQHML5PNhWMvkKJ6+87hij89Dg/bX4 h7vHCP7HJ4nssAAa3sfalWO21mZxTU4FVZssDzassCgq9GELwCuesRoZ2 GpC3SP7r5hSZReMrZg0zjTuvt9lIaAg5R5WtMWyrRmD0MPvEM5ppIIqbT Q==;
X-IronPort-AV: E=Sophos;i="5.31,557,1473076800"; d="scan'208";a="112467617"
X-Ironport-Source: - Outgoing - Outgoing
Received: from (HELO ([]) by with ESMTP/TLS/AES256-SHA; 28 Oct 2016 22:58:17 +1300
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 28 Oct 2016 22:58:18 +1300
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Fri, 28 Oct 2016 22:58:17 +1300
From: Peter Gutmann <>
To: Hanno Böck <>
Thread-Topic: [Cfrg] Security proofs v DH backdoors
Thread-Index: AQHSMEAWZy2e+SPalEyp/G+CJ2BAv6C9nFXG//8p9wCAANysfA==
Date: Fri, 28 Oct 2016 09:58:16 +0000
Message-ID: <>
References: <> <> <> <> <> <20161027125120.4d260334@pc1> <>,<20161028114758.6a361db1@pc1>
In-Reply-To: <20161028114758.6a361db1@pc1>
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: Fri, 28 Oct 2016 09:58:21 -0000

Hanno Böck <> writes:

>Can you elaborate what brittleness you mean?

Uh, faults, as I said in my original message.  Any data corruption, bit-flips,
RNG faults, anything, and you end up leaking the private key.

>So your general idea here is that there are situations where people are
>constrained not to use ECC with another curve, but they *can* use DH with
>another parameter set?

They've been using DH forever, and will continue to do so.  They won't move to
an entirely new and/or extremely brittle algorithm class (and, in the case of
TLS 1.3/2.0, an entirely new protocol).

>Would it satisfy the needs of people if there simply was some kind of
>document (could be an RFC, but maybe also just an errata) saying that the DH
>parameters from 7919 may be used outside TLS? (not sure if this has to be
>explicitly stated, but if it helps people, why not?)

Uh, that's exactly the question I asked in my post...

I think it's more of a political than technical problem.  If you (meaning the
server) can generate your own parameters you're fine, if you're an industry
body you can mandate whatever it is you feel comfortable mandating, so it's
mostly a case of asking who would want/need standard parameter sets, and what
would it take to keep them happy about how they're generated?  Look at the
Brainpool curves for an example, one group of people regard them as perfectly
good NUMS values, another group regards them as having too much scope for
manipulation.  So it's a case of how far down the rabbit hole do you want to
go for generation?