On Tue, Jan 5, 2016 at 9:00 AM, Paul Wouters <p...@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@randombit.net > http://lists.randombit.net/mailman/listinfo/cryptography -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
