[cryptography] What the heck is RFC 5114?

Antonio Sanso asanso at adobe.com
Tue Jan 5 15:27:05 EST 2016

wow, thanks a lot Paul for your great answer!!

See also inline...
On Jan 5, 2016, at 6:00 PM, Paul Wouters <paul at cypherpunks.ca<mailto:paul at cypherpunks.ca>> wrote:

On Tue, 5 Jan 2016, Antonio Sanso wrote:

Subject: [cryptography] What the heck is RFC 5114?

Comments/answers are welcomed :)


Seeing that you are quoting my information from nohats.ca<http://nohats.ca>, let me reply here :)

RFC5114 support was added to openswan (before the rename/fork to
libreswan) to attempt to move more towards ECC. But RFC-5114 lists both
ECP and classic groups. When we added these (only non-ECP so DH 22,23,24),
I wondered how much preference we should give these and I started looking
into the origin of the groups. Which is when I could only find the quoted
comment on the origin being BBN and that there wasn't much discussion
and that the IETF did not really think these were needed but there was
no strong opposition so these three made it in. That the origin of the
numbers used was unknown. So therefor, libreswan (and openswan) do not enable
DH 22,23,24 from RFC5114 unless explicitely configured.

See also: https://www.ietf.org/mail-archive/web/ipsec/current/msg06141.html

> I am somewhat confused, are the modp groups 22, 23 & 24 suppose to use
> one of these new methods and that is why "q" is given in rfc 5114?
> Or am I to ignore this and just continue with existing way
> where "q" is not used and there aren't any additional computations
> to compute x.

Short answer: it doesn't really matter; the old way is safe (for DH).

Longer answer: FIPS 186-3 was written about generating values for DSA,
not DH.  Now, for DSA, there is a known weakness if the exponents you
use are biased; these algorithms used in FIPS 186-3 were designed to
make sure that the exponents are unbiased (or close enough not to
matter).  DH doesn't have similar issues, and so these steps aren't
required (although they wouldn't hurt either).


For these new groups, (p-1)/q is quite large, and in all three cases,
has a number of small factors (now, NIST could have defined groups where
(p-1)/q has 2 as the only small factor; they declined to do so).  For
example, for group 23 (which is the worse of the three), (p-1)/q ==  2 *
3 * 3 * 5 * 43 * 73 * 157 * 387493 * 605921 * 5213881177 * 3528910760717
* 83501807020473429349 * C489 (where C489 is a 489 digit composite
number with no small factors).  The attacker could use this (again, if
you don't validate the peer value) to effective cut your exponent size
by about 137 bits with using only  O(2**42) time); if you used 224 bit
exponents, then the attacker would cut the work used to find the rest
of the exponent to about O(2**44) time.  Obviously, this is not

do you have some  more details link about this attack ? (I know how to do for g=2 but I am not sure I can manage the other cases...)

Note also: http://www.potaroo.net/ietf/idref/draft-grieco-suite-vpn-d/

  In this document, we make use of Diffie-Hellman Group 14 in Suite
  VPN-D to provide 2048 bit MODP for IKE.  Diffie-Hellman Group 24
  [RFC5114] might also be considered to for this purpose.  However, the
  authors note, the prime chosen for Group 24 is not a safe prime and
  modified IKE hanlding based on public key validation routines might
  be required.

Note that it seems exim might use these groups for TLS:

As per my blog

  *   Bouncy Castle just changed the default to 2048 just few months ago<https://github.com/bcgit/bc-java/commit/39879ec3744842711c2570b6a5f86346058183f0> (but still use rfc5114)
  *    OpenSSL has built-in support for these parameters from OpenSSL 1.0.2




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.randombit.net/pipermail/cryptography/attachments/20160105/60135f79/attachment-0001.html>

More information about the cryptography mailing list