Comment by SaveTheRbtz | Hacker News Reader

Comment by SaveTheRbtz | Hacker News Reader

Parent Full thread

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/fip...

[SEC-2v2] http://www.secg.org/download/aid-784/sec2-v2.pdf

[safecurves] http://safecurves.cr.yp.to/index.html

[Curve25519] http://cr.yp.to/ecdh.html

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).

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

Reply on news.ycombinator.com