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

Hi Paul,

Thank you for sharing the paper.

A conclusion of the paper was "Our results are yet another reminder that 1024-bit primes should be considered insecure for the security of cryptosystems based on the hardness of discrete logarithms. The discrete logarithm computation for our backdoored prime was only feasible because of the 1024-bit size, and the most effective protection against any backdoor of this type has always been to use key sizes for which any computation is infeasible. NIST recommended transitioning away from 1024-bit key sizes for DSA, RSA, and Diffie-Hellman in 2010 [6]."

NIST has been urging users to move away from groups with 1024- bit p and 160-bit q  for many years now.

In our document, we stated that group generators "should" provide their seeds. The reason for having "should" instead of "shall (must)" was that anyone could run our suggested method to generate their own group. A user who generates his/her own group for her/his own application could have a choice of publishing the seed or not.  If a user had a contractor/third party to generate a group for him/her, he or she could ask for all documentation about the whole process.

Quynh.

________________________________
From: IPsec <ipsec-bounces@ietf.org> on behalf of Paul Wouters <paul@nohats.ca>
Sent: Sunday, October 9, 2016 5:26 PM
To: ipsec@ietf.org WG
Cc: saag@ietf.org
Subject: [IPsec] trapdoor'ed DH (and RFC-5114 again)

Released a few days ago:

         http://eprint.iacr.org/2016/961

         A kilobit hidden SNFS discrete logarithm computation
         Joshua Fried and Pierrick Gaudry and Nadia Heninger and Emmanuel Thomé

         We perform a special number field sieve discrete logarithm
         computation in a 1024-bit prime field. To our knowledge, this
         is the first kilobit-sized discrete logarithm computation ever
         reported for prime fields. This computation took a little over
         two months of calendar time on an academic cluster using the
         open-source CADO-NFS software.

Basically, this paper shows how to make a DH group of 1024 modp
with a backdoor, in two months of academic computing resources,

The paper mentions 5114 a few times:

         RFC 5114 [33] specifies a number of groups for use with
         Diffie-Hellman, and states that the parameters were drawn
         from NIST test data, but neither the NIST test data [39] nor
         RFC 5114 itself contain the seeds used to generate the finite
         field parameters

And concludes:

         Both from this perspective, and from our more modern one, dismissing the
         risk of trapdoored primes in real usage appears to have been a mistake,
         as the apparent difficulties encountered by the trapdoor designer in 1992
         turn out to be easily circumvented. A more conservative design decision
         for FIPS 186 would have required mandatory seed publication instead of
         making it optional.  As a result, there are opaque, standardized 1024-bit
         and 2048-bit primes in wide use today that cannot be properly verified.

This is the strongest statement yet that I've seen to not trust any
of the RFC-5114 groups.

The latest 4307bis document has these groups (22-24) as SHOULD NOT,
stating:

         Group 22, 23 and 24 or 1024-bit MODP Group with 160-bit, and
         2048-bit MODP Group with 224-bit and 256-bit Prime Order Subgroup
         have small subgroups, which means that checks specified in the
         "Additional Diffie-Hellman Test for the IKEv2" [RFC6989] section
         2.2 first bullet point MUST be done when these groups are used.
         These groups are also not safe-primes.  The seeds for these groups
         have not been publicly released, resulting in reduced trust in
         these groups.  These groups were proposed as alternatives for
         group 2 and 14 but never saw wide deployment.  It is expected
         in the near future to be further downgraded to MUST NOT.

I'm proposing it is time to change this to MUST NOT for 4307bis.

Possibly, we should do this via SAAG in general, and then follow SAAG's
advise in IPSECME.

Is there _any_ reason why group 22-24 should not be MUST NOT ?

Paul

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec