[Swan-dev] [cryptography] What the heck is RFC 5114? (fwd)

[Paul Wouters]

FYI,

Paul

---------- Forwarded message ----------
Date: Tue, 5 Jan 2016 12:00:52
From: Paul Wouters <paul at cypherpunks.ca>
Cc: "cryptography at randombit.net" <cryptography at randombit.net>
To: Antonio Sanso <asanso at adobe.com>
Subject: Re: [cryptography] What the heck is RFC 5114?

On Tue, 5 Jan 2016, Antonio Sanso wrote:

>  Subject: [cryptography] What the heck is RFC 5114?
>
>  Comments/answers are welcomed :)
>
>  http://intothesymmetry.blogspot.it/2016/01/what-heck-is-rfc-5114.html

Seeing that you are quoting my information from 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
 	 acceptable.

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:
 	 https://bettercrypto.org/static/applied-crypto-hardening.pdf

Paul