ECC curves that are safe safecurves.cr.yp.to
DJ Bernstein and Tanja Lange did a study on which ECC curves are safe to implement and use, found at http://safecurves.cr.yp.to/ YMMV as per the snowden releases but for now curve p25514 appears to be safe AND accessible in at least 2 cli type implementations. To be avoided at present is SECCURE-0.4 and below(no safe curves as per the bernstein document) GH -- Tentacle #99 ecc public key curve p25519(pcp 0.15) 1l0$WoM5C8z=yeZG7?$]f^Uu8.g>4rf#t^6mfW9(rr910 Governments are instituted among men, deriving their just powers from the consent of the governed, that whenever any form of government becomes destructive of these ends, it is the right of the people to alter or abolish it, and to institute new government, laying its foundation on such principles, and organizing its powers in such form, as to them shall seem most likely to effect their safety and happiness.’ https://github.com/TLINDEN/pcp.git to get pcp(curve25519 cli)
gwen hastings <gwen@cypherpunks.to> writes:
DJ Bernstein and Tanja Lange did a study on which ECC curves are safe to implement and use, found at http://safecurves.cr.yp.to/
Some of their objections seem pretty subjective though, I mean they don't like the Brainpool curves because of: Several unexplained decisions: Why SHA-1 instead of, e.g., RIPEMD-160 or SHA-256? Why use 160 bits of hash input independently of the curve size? Why pi and e instead of, e.g., sqrt(2) and sqrt(3)? Why handle separate key sizes by more digits of pi and e instead of hash derivation? Why counter mode instead of, e.g., OFB? Why use overlapping counters for A and B (producing the repeated 26DC5C6CE94A4B44F330B5D9)? Why not derive separate seeds for A and B? Is that really a big deal? SHA-1 vs. RIPEMD-160. Peter.
participants (2)
-
gwen hastings
-
Peter Gutmann