[cryptography] What the heck is RFC 5114?

Watson Ladd 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 :)
>>
>> 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.

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:
>         https://bettercrypto.org/static/applied-crypto-hardening.pdf
>
> Paul
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.


More information about the cryptography mailing list