[cryptography] What the heck is RFC 5114?
watsonbladd at gmail.com
Tue Jan 5 12:12:34 EST 2016
On Tue, Jan 5, 2016 at 9:00 AM, Paul Wouters <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, 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
> 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
> > 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
> Longer answer: FIPS 186-3 was written about generating values for
> not DH. Now, for DSA, there is a known weakness if the exponents
> 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
> has a number of small factors (now, NIST could have defined groups
> (p-1)/q has 2 as the only small factor; they declined to do so).
> example, for group 23 (which is the worse of the three), (p-1)/q ==
> 2 *
> 3 * 3 * 5 * 43 * 73 * 157 * 387493 * 605921 * 5213881177 *
> * 83501807020473429349 * C489 (where C489 is a 489 digit composite
> number with no small factors). The attacker could use this (again,
> you don't validate the peer value) to effective cut your exponent
> by about 137 bits with using only O(2**42) time); if you used 224
> exponents, then the attacker would cut the work used to find the
> of the exponent to about O(2**44) time. Obviously, this is not
> 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.
Do any implementations validate peer values? This sounds like a fairly
expensive operation, an additional modular exponentiation.
I'll try to check if exim does: anyone got a server they don't mind me
trying to pwn?
> Note that it seems exim might use these groups for TLS:
> cryptography mailing list
> cryptography at randombit.net
"Man is born free, but everywhere he is in chains".
More information about the cryptography