3 ms·

And what does it mean in Standard [FIPS186-2] [SEC-2v2] terms? That one should avoid using sect{163,233,239,283,409,571}k1 and sect{163,233,239,283,409,571}r1 c

And what does it mean in Standard [FIPS186-2] [SEC-2v2] terms? That one should avoid using sect{163,233,239,283,409,571}k1 and sect{163,233,239,283,409,571}r1 curves? But there are also rumors that secp{192,224,256,384,521}r1 are backdoored by NSA. This leaves only secp{192,224,256,384,521}k1 which are considered "unsafe" by Daniel J. Bernstein [safecurves]. So the only hope is to wait for [Curve25519] to be widely supported? PS. Bitcoin using secp256k1 which is Koblitz GFp curve. [FIPS186-2] http://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2.pdf http://csrc.nist.gov/publications/fips/archive/fips186-2/fip... [SEC-2v2] http://www.secg.org/download/aid-784/sec2-v2.pdf http://www.secg.org/download/aid-784/sec2-v2.pdf [safecurves] http://safecurves.cr.yp.to/index.html http://safecurves.cr.yp.to/index.html [Curve25519] http://cr.yp.to/ecdh.html http://cr.yp.to/ecdh.html

djmdjm 12y ago
I haven't heard anyone recommending against the GF2m curve fields recommended by the IETF and NIST standards. Take this with an appropriately large grain of salt - I haven't followed the fallout of Joux' work very closely (because I don't use anything that uses GF2m fields).
- SaveTheRbtz 12y ago
  DJB says following about all non-prime fields [1]: > Is ECDLP broken for non-prime fields? No. However, the security story for non-prime fields (e.g., binary extension fields) is more complicated and less stable than the security story for prime fields, as illustrated by 1998 Frey, 2002 Gaudry–Hess–Smart, 2009 Gaudry, and 2012 Petit–Quisquater. 2006 Bernstein stated that prime fields "have the virtue of minimizing the number of security concerns for elliptic-curve cryptography". Similarly, the Brainpool standard and NSA's Suite B standards require prime fields. There is general agreement that prime fields are the safe, conservative choice for ECC. [1] http://safecurves.cr.yp.to/field.html http://safecurves.cr.yp.to/field.html

djmdjm 12y ago

I haven't heard anyone recommending against the GF2m curve fields recommended by the IETF and NIST standards. Take this with an appropriately large grain of salt - I haven't followed the fallout of Joux' work very closely (because I don't use anything that uses GF2m fields).

SaveTheRbtz 12y ago
DJB says following about all non-prime fields [1]: > Is ECDLP broken for non-prime fields? No. However, the security story for non-prime fields (e.g., binary extension fields) is more complicated and less stable than the security story for prime fields, as illustrated by 1998 Frey, 2002 Gaudry–Hess–Smart, 2009 Gaudry, and 2012 Petit–Quisquater. 2006 Bernstein stated that prime fields "have the virtue of minimizing the number of security concerns for elliptic-curve cryptography". Similarly, the Brainpool standard and NSA's Suite B standards require prime fields. There is general agreement that prime fields are the safe, conservative choice for ECC. [1] http://safecurves.cr.yp.to/field.html http://safecurves.cr.yp.to/field.html