On Thu, Mar 26, 2015 at 5:55 PM, Johan Wevers <joh...@vulcan.xs4all.nl> wrote: > On 26-03-2015 9:59, Mike Ingle wrote: > >> Is this just a backward >> compatibility thing, or is the security of ECC keys not fully trusted yet? > > The buzz about Dual_EC_DRBG made it clear that it is possible to design > curves where the designers have access to data that allows them to > compromise the system. Wether the curves used in a given implementation > are suspected to possibly have such a weakness is a matter of debate. I > didn't check the status of this for the curves used in GnuPG 2.1.
Although Dual_EC_DRBG uses elliptic curves, the weakness in that algorithm lies with the alleged backdoor in Dual_EC_DRBG itself and not in the mathematics behind elliptic curve crypto in general. GnuPG 2.1 implements the following curves: (1) Curve 25519 (2) NIST P-256 (3) NIST P-384 (4) NIST P-521 (5) Brainpool P-256 (6) Brainpool P-384 (7) Brainpool P-512 People have raised concerns about the NIST curves, but they are part of the RFC 6637 standard so compliant programs must implement P-256, may implement P-384, and should implement P-521. To address potential concerns with the NIST curves, GnuPG also supports the Brainpool curves which are similar in structure to the NIST curves but use parameters chosen from nothing-up-my-sleeve numbers and so should be reasonably trustworthy. Still, the structure of such curves leaves a bit to be desired (see http://safecurves.cr.yp.to/ for details, I'm hardly an expert). Additionally, GnuPG implements the non-standard Curve25519 (but only for signing at the moment -- encryption will come later after things have been standardized) which should be safe. Cheers! -Pete -- Pete Stephenson _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
