Re: [Cfrg] malicious DH base points [was Re: should the CFRG really strive for consensus?]

"Paterson, Kenny" <> Wed, 31 December 2014 16:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7DCC51A9114 for <>; Wed, 31 Dec 2014 08:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bGs2kWesq41s for <>; Wed, 31 Dec 2014 08:08:01 -0800 (PST)
Received: from ( [IPv6:2a01:111:f400:fe00::620]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CF9C1A9105 for <>; Wed, 31 Dec 2014 08:08:00 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 31 Dec 2014 16:02:51 +0000
Received: from ([]) by ([]) with mapi id 15.01.0049.002; Wed, 31 Dec 2014 16:02:51 +0000
From: "Paterson, Kenny" <>
To: Dan Brown <>, "Scott Fluhrer (sfluhrer)" <>, Adam Langley <>, Christoph Anton Mitterer <>
Thread-Topic: [Cfrg] malicious DH base points [was Re: should the CFRG really strive for consensus?]
Thread-Index: AdAlEKR+j0vH2sKEQBKKNUfeAAj9hwAApFCA
Date: Wed, 31 Dec 2014 16:02:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
authentication-results: spf=none (sender IP is );
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384;
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB384;
x-forefront-prvs: 0442E569BC
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(377454003)(199003)(189002)(51704005)(24454002)(479174004)(20776003)(97736003)(101416001)(4396001)(87936001)(107046002)(66066001)(86362001)(64706001)(92566001)(19580395003)(105586002)(46102003)(21056001)(31966008)(15975445007)(68736005)(76176999)(77156002)(120916001)(62966003)(102836002)(2950100001)(50986999)(40100003)(19580405001)(77096005)(74482002)(36756003)(99396003)(106356001)(2900100001)(54356999)(2656002)(122556002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2014 16:02:51.1303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB384
Cc: "" <>
Subject: Re: [Cfrg] malicious DH base points [was Re: should the CFRG really strive for consensus?]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 31 Dec 2014 16:08:08 -0000


Please, let's desist from these kinds of side-track discussions. They clog
up peoples' inboxes and make it hard to see the wood from the trees in
what is already a heavily-wooded discussion.



On 31/12/2014 15:44, "Dan Brown" <> wrote:

>Right, I should have said hypothetical rather possible (which can also be
>read as able).
>So, under the paper's unlikely MDH hypothesis, a fast generator could be
>weak, or worse, an unexplained random-looking generator could be weak. To
>me, the best countermeasure to this hypothetical attack would be an
>explainable randomish base point. Or, one
> can just use the fastest base point, and argue this hypothesis is too
>unlikely to fret over.
>Aside: I think X9.62-2005 added an option to have pseudorandom base
>Best regards, 
>-- Dan
>From: Scott Fluhrer (sfluhrer)
>Sent: Wednesday, December 31, 2014 10:30 AM
>To: Dan Brown; Adam Langley; Christoph Anton Mitterer
>Subject: RE: [Cfrg] malicious DH base points [was Re: should the CFRG
>really strive for consensus?]
>Actually, that paper doesn¹t actually say ³it¹s possible to pick a
>malicious generator from a prime-sized group².  Instead, it (actually,
>claim 9) says ³if
> we knew of a generator/KDF pair which made deriving the shared secret
>easy, someone setting up the group could use that to select a
>random-looking generator that, with that KDF, contains a trap door that
>he could exploit².
>If anything, that paper can be construed to be an argument for a
>nonrandom-looking generator (because that doesn¹t give anyone a chance to
>build in the above
> trap door).
>From: Cfrg []
>On Behalf Of Dan Brown
>Sent: Wednesday, December 31, 2014 10:07 AM
>To: Adam Langley; Christoph Anton Mitterer
>Subject: [Cfrg] malicious DH base points [was Re: should the CFRG really
>strive for consensus?]
>The paper talks about the possibility of malicious base points for DH:
>Boaz Tsaban: Fast generators for the Diffie-Hellman
> key agreement protocol and malicious standards. IACR
> Cryptology ePrint Archive 2005
>aban05>: 231 (2005)
>It may be far-fetched, but the paper seems to show that the independence
>of DH from the base point is not quite a mathematical certainty, unless
> paper has been refuted in further research.
>Best regards,
>-- Dan
>Adam Langley
>Wednesday, December 31, 2014 9:45 AM
>Christoph Anton Mitterer
>Re: [Cfrg] should the CFRG really strive for consensus?
>On Dec 31, 2014 1:50 PM, "Christoph Anton Mitterer"
><> wrote:
>> I think it's really a bad idea for the CFRG to strive so much for
>> consensus.
>If you believe in the security of curve25519 then you also believe in the
>security of Microsoft's current position at ~128 bits. They have the same
>structure and thus strictly the same strength.
>There's /no/ possibility of weakening anything, mathematically, with a
>different base point (in the correct subgroup) or by using an isogeny.
>IRTF groups do not, technically, have to reach consensus. However,
>everyone does have to function on the same Internet at the end of the day.