Enabling and using ECC keys (any reason not to?)

[Pete Stephenson]

On Thu, Mar 26, 2015 at 5:55 PM, Johan Wevers <johanw at 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