and the happy end: OpenSSL Key Recovery Attack on DH small subgroups (CVE-2016-0701)
http://intothesymmetry.blogspot.ch/2016/01/openssl-key-recovery-attack-on-dh-small.html Thanks a lot guys!! Specially to Paul! regards antonio On Jan 6, 2016, at 3:08 PM, Antonio Sanso <asa...@adobe.com<mailto:asa...@adobe.com>> wrote: hi On Jan 5, 2016, at 9:27 PM, Antonio Sanso <asa...@adobe.com<mailto:asa...@adobe.com>> wrote: wow, thanks a lot Paul for your great answer!! See also inline... On Jan 5, 2016, at 6:00 PM, Paul Wouters <p...@cypherpunks.ca<mailto: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<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 acceptable. 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…) I guess I found the answer :) http://www.ietf.org/rfc/rfc2785.txt and http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.44.5296 should suffice :) regards antonio 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 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 regards antonio Paul
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
