Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Tue, 10 Sep 2013 00:25:20 +0100 Peter Fairbrother wrote: > On 09/09/13 23:03, Perry E. Metzger wrote: > > >> On Mon, 9 Sep 2013, Daniel wrote: > >> [...] They are widely used curves and thus a good way to reduce > >> conspiracy theories that they were chosen in some malicious way > >> to subvert DRBG. > > > > Er, don't we currently have documents from the New York Times and > > the Guardian that say that in fact they *did* subvert them? > > > > Yes, a week ago this was paranoia, but now we have confirmation, > > so it is no longer paranoia. > > I did not see that, and as far as I can tell there is no actual > confirmation. Quoting: Cryptographers have long suspected that the agency planted vulnerabilities in a standard adopted in 2006 by the National Institute of Standards and Technology and later by the International Organization for Standardization, which has 163 countries as members. Classified N.S.A. memos appear to confirm that the fatal weakness, discovered by two Microsoft cryptographers in 2007, was engineered by the agency. The N.S.A. wrote the standard and aggressively pushed it on the international group, privately calling the effort “a challenge in finesse.” http://www.nytimes.com/2013/09/06/us/nsa-foils-much-internet-encryption.html?pagewanted=all This has generally been accepted to only match the NIST ECC RNG standard, i.e. Dual_EC_DRBG, with the critique in question being "On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng" which may be found here: http://rump2007.cr.yp.to/15-shumow.pdf Do you have an alternative theory? Perry -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On 09/09/13 23:03, Perry E. Metzger wrote: On Mon, 9 Sep 2013, Daniel wrote: [...] They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. Er, don't we currently have documents from the New York Times and the Guardian that say that in fact they *did* subvert them? Yes, a week ago this was paranoia, but now we have confirmation, so it is no longer paranoia. I did not see that, and as far as I can tell there is no actual confirmation. Also, the known possible subversion of DRBG did not involve curve selection, but selection of a point to be used in DRBG. I think Kristian G has posted about that. As to elliptic curves, there are only two of significance, in terms of being widely used: they are NIST P-256 and NIST P-384. NIST P-224 is also occasionally used. These are the same curves as the secp256/384r1 curves, and the same curves as almost any other 256-bit or 384-bit curves you might want to mention - eg the FIPS 186-3 curves, and so on. These are all the same curves. They all began in 1999 as the curves in the (NIST) RECOMMENDED ELLIPTIC CURVES FOR FEDERAL GOVERNMENT USE csrc.nist.gov/groups/ST/toolkit/documents/dss/NISTReCur.pdf The way they were selected is supposed to be pseudo-random based on SHA-1, though it's actually not quite like that (or not even close). Full details, or at least all of the publicly available details about the curve selection process, are in the link, but as I wrote earlier: "Take FIPS P-256 as an example. The only seed which has been published is s= c49d3608 86e70493 6a6678e1 139d26b7 819f7e90 (the string they hashed and mashed in the process of deriving c). I don't think they could reverse the perhaps rather overly-complicated hashing/mashing process, but they could certainly cherry-pick the s until they found one which gave a c which they could use. c not being one of the usual parameters for an elliptic curve, I should explain that it was then used as c = a^3/b^2 mod p. However the choice of p, r, a and G was not seeded, and the methods by which those were chosen are opaque. I don't really know enough about ECC to say whether a perhaps cherry-picked c = a^3/b^2 mod p is enough to ensure that the resulting curve is secure against chosen curve attacks - but it does seem to me that there is a whole lot of wiggle room between a cherry-picked c and the final curve." -- Peter Fairbrother ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Mon, 9 Sep 2013 14:07:58 +0300 Alexander Klimov wrote: > On Mon, 9 Sep 2013, Daniel wrote: > > Is there anyone on the lists qualified in ECC mathematics that can > > confirm that? > > NIST SP 800-90A, Rev 1 says: > > The Dual_EC_DRBG requires the specifications of an elliptic curve > and two points on the elliptic curve. One of the following NIST > approved curves with associated points shall be used in > applications requiring certification under [FIPS 140]. More details > about these curves may be found in [FIPS 186], the Digital > Signature Standard. > > > And what ramifications it has, if any.. > > No. They are widely used curves and thus a good way to reduce > conspiracy theories that they were chosen in some malicious way to > subvert DRBG. > Er, don't we currently have documents from the New York Times and the Guardian that say that in fact they *did* subvert them? Yes, a week ago this was paranoia, but now we have confirmation, so it is no longer paranoia. -- Perry E. Metzgerpe...@piermont.com ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
[Cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
Forwarded without permission, hence anonymized: " Hey, I had a look at SEC2 and the TLS/SSH RFCs. SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG! TLS specifies you can use those two curves as well... Surely that's not coincidence.. " signature.asc Description: Digital signature ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
On Mon, 9 Sep 2013, Daniel wrote: > Is there anyone on the lists qualified in ECC mathematics that can > confirm that? NIST SP 800-90A, Rev 1 says: The Dual_EC_DRBG requires the specifications of an elliptic curve and two points on the elliptic curve. One of the following NIST approved curves with associated points shall be used in applications requiring certification under [FIPS 140]. More details about these curves may be found in [FIPS 186], the Digital Signature Standard. > And what ramifications it has, if any.. No. They are widely used curves and thus a good way to reduce conspiracy theories that they were chosen in some malicious way to subvert DRBG. -- Regards, ASK ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography
Re: [Cryptography] [cryptography] SSH uses secp256/384r1 which has the same parameters as what's in SEC2 which are the same the parameters as specified in SP800-90 for Dual EC DRBG!
9. sep. 2013 kl. 10:45 skrev Eugen Leitl : > Forwarded without permission, hence anonymized: > " > Hey, I had a look at SEC2 and the TLS/SSH RFCs. SSH uses secp256/384r1 > which has the same parameters as what's in SEC2 which are the same the > parameters as specified in SP800-90 for Dual EC DRBG! > TLS specifies you can use those two curves as well... > Surely that's not coincidence.. > " The curves are standard NIST curves. They were the curves you used until about now. That they are the same everywhere is no surprise. The "problem" with Dual-EC-DRBG was that a point that should have been generated verifiably at random was not generated verifiably at random. There's no reason to believe it wasn't, but it was a stupid mistake that should not have been made, and that has now been blown out of all proportion. Users, if there are any, should generate their own points verifiably at random. If you reuse one or more points from Dual-EC-DRBG as generators in other standards, it is of no matter. Even if the points are carefully chosen, they cannot compromise those other standards. (DLOG is essentially independent of the generator.) There's no reason to be paranoid, just because the NSA is out to get you. -- Kristian Gjøsteen ___ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography