Enabling and using ECC keys (any reason not to?)
pete at heypete.com
Thu Mar 26 18:40:15 CET 2015
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.
More information about the Gnupg-users