Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)

Stephen Kent <> Tue, 18 October 2016 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 761941294A7; Tue, 18 Oct 2016 07:47:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9r39hOuNwoZu; Tue, 18 Oct 2016 07:47:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E029C12948C; Tue, 18 Oct 2016 07:47:04 -0700 (PDT)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id u9IEl0pY024719 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 Oct 2016 14:47:02 GMT
Received: from ([]) by ( with ESMTPS id u9IEl0Ie002381 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NOT); Tue, 18 Oct 2016 14:47:00 GMT
Received: from ([]:43572 helo=COMSEC.fios-router.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1bwVfQ-000CJu-Az; Tue, 18 Oct 2016 10:47:00 -0400
From: Stephen Kent <>
To: Paul Wouters <>, Yoav Nir <>
References: <> <> <> <> <>
Message-ID: <>
Date: Tue, 18 Oct 2016 10:47:00 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-18_07:, , signatures=0
Archived-At: <>
Cc: " WG" <>, Security Area Advisory Group <>
Subject: Re: [saag] [IPsec] trapdoor'ed DH (and RFC-5114 again)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Advisory Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 18 Oct 2016 14:47:06 -0000


It's  been over 8 years since this RFC was published, and I have not 
looked at it since then. My recollection is that we wrote 5114 because 
an IPsec developer approached me and said that he wanted to support 
these groups in a product. He said that he wanted test vectors for the 
groups, consistent with what we have done for many other algs. I 
persuaded Matt to generate the RFC because it was a relatively easy task 
a good way for Matt to get acquainted with the RFC process.

As to your question, I have no info about how the NIST DH values were 
generated. However, I do agree with Yoav and Tero that it seems unduly 
prejudicial to declare these to be a MUST NOT. The fact that one can 
generate trap-doored DH values that cannot be detected is not the same 
as having proof that a given set of values have been generated in that 
fashion. Moreover, if one interprets a MUST NOT in this context to mean 
that an implementation supporting any of these groups is non-compliant, 
then that unfairly penalizes existing implementations, as Tero noted. 
Moreover, if the concern raised by the paper (which I have read) is with 
MODP groups of size 1024 (or smaller), only 1 of the groups in 5114 fits 
that criteria (section 2.1).

I have not tracked the status of these NIST groups re evaluation 
criteria like FIPS 140-2. If these groups are approved for use in 
products evaluated under that FIPS (I don't know if they are), 
deprecating them creates a possible conundrum for vendors who want to 
comply with RFCs and with FIPS evaluation criteria. Thus I suggest a 
less dramatic response than declaring all of the groups in 5114 to be 

I'm not a vendor of any crypto products (these days), and I've never 
been a crypto mathematician. So my views are based only on what I recall 
about the creation of 5114 and about IETF crytpo standards practices in