----- Original Message ----- > On Nov 25, 2013, at 1:02 AM, Jan-Frode Myklebust <[email protected]> wrote: > > > On Mon, Nov 25, 2013 at 08:22:35AM +0000, Igor Galić wrote: > >> > >>> and for stud: > >>> > >>> https://github.com/bumptech/stud/pull/61/files > >> > >> Wow. That's bad. That looks specifically for the *bad* NSA curve constants > >> before initializing the ec code. That's not something I'd rely on, since > >> not even NIST is any more. > > > > Are there any other relevant curve constants that's usable? Looks to me > > like everyone is using NIST P-384 or NIST P-256, and these are the only > > once available as named curves in my openssl library. > > P-256 is also recommended here, > https://www.imperialviolet.org/2011/11/22/forwardsecret.html
That's from 2010, a long time ago ;) To quote Bruce Schneier, "I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry." - https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html#c1675929 Every curve that comes from J. A. Solinas I would declare on the simple basis that they work for the NSA as untrustworthy, no matter whether these constants are good or bad or NIST recommended and in an RFC simply for having all together produced and standardized DUAL_EC_DRBG. Frankly, I think we should prepare the code, but wait out the storm as to which algorithms to chose. > J ++ i Igor Galić Tel: +43 (0) 664 886 22 883 Mail: [email protected] URL: http://brainsware.org/ GPG: 8716 7A9F 989B ABD5 100F 4008 F266 55D6 2998 1641
