ECC in (Open)PGP

Question

How is with the support for ECC (Elliptic Curve Cryptography) in (Open)PGP so far? It seems that GnuPG (The GNU Privacy Guard) doesn't have an official implementation - but I did find the gnupg-ecc project (ECC-enabled GnuPG per RFC 6637) on Google Code:

This project brought to life Elliptic Curve Cryptography support in OpenPGP as an end-user feature. Users can simply select an ECC key generation option in

gpg2 --gen-key

and then use the generated public key as they normally would use any other public key, as shown here.

I know that Symantec supports ECC. Are there reasons not to use ECC?

EDIT

I did some more research and found out that ECC found it's way to the main line of gnupg a long time agao, but only in the developer version:

$ gpg2 --expert --gen-key
gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
Please select what kind of key you want:
    (1) RSA and RSA (default)
    (2) DSA and Elgamal
    (3) DSA (sign only)
    (4) RSA (sign only)
    (7) DSA (set your own capabilities)
    (8) RSA (set your own capabilities)
    (9) ECDSA and ECDH
   (10) ECDSA (sign only)
   (11) ECDSA (set your own capabilities)
Your selection?`

Answer 1

I see two main reasons why you might not want to use ECC:

Practical reason: communication necessarily involves two parties, the sender and the receiver. ECC can be used only if both sender and receiver support it. As you noticed, existing, deployed implementations are not necessarily up to it yet; if you use an ECC public key, people may send you messages encrypted with that key, or verify your signatures with that key, only if their OpenPGP implementation includes the relevant code.

So your choice of ECC or not ECC depends on whether you want to maximize interoperability or prefer to be an "early adopter" (although in the case of ECC, really early adopters are already there; ECC is becoming mainstream).

Moral reason: mathematically, we don't have proof that any of the cryptographic algorithms that we employ is really robust against attacks. We don't even know if it is mathematically possible to be robust against attacks. Right now, the only method we have to assess the strength of any cryptographic algorithm is to define it, and then let a lot of cryptographers work on it for some years. If none of these smart people found anything wrong with the algorithm, then you can know that if the algorithm is weak, then, at least, it is not obviously weak.

Elliptic Curves have been proposed as objects suitable for cryptography in 1985 (by Koblitz and Miller, independently). The mathematics of elliptic curves have been studied for about 40 years before that. So ECC can sport about 70 years of exposure, 30 of which in a definitely cryptographic setting. That's not bad.

Integer factorization, on which RSA is based, can boast 35 years of cryptographic exposure (RSA was proposed in 1978), and more than a whooping 2500 years for the underlying mathematics. Therefore it may be argued that the security of RSA is "more understood" than that of elliptic curves.

---

Personally, I think that ECC is mature enough to be deployed, and since ECC are highly fashionable, implementations become commonplace and we can expect GnuPG to soon align itself. Thus, my recommendation is: ECC is fine, as long as you are ready to encounter some interoperability issues for a few years.

(One dark spot of ECC deployment is that there are very few "generic" ECC implementations; most implementations are specific to a restricted set of supported curves, often restricted to the two NIST P-256 and P-384 curves. The choice of curve for your key thus has a non-trivial impact on interoperability. P-256 is fine for security, though, so you can use it and stop worrying.)

Answer 2

Currently, ECC is supported in GnuPG 2.1 beta. You can compile it from source and see for yourself that the following curves are supported:

nistp256 nistp384 nistp521 brainpoolP256r1 brainpoolP384r1 brainpoolP512r1 secp256k1