Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?


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: 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?`
share|improve this question
ECC is the new 'thing' being pushed by NSA/NIST. It's very strong with far less overhead (Same security with a much smaller key size compared to RSA). There is no reason not to use ECC as your asymmetric key algorithm. – Rell3oT Apr 19 '13 at 1:57
@Rell3oT do you know of any reason why it hasn't found its way to the gnupg offical implementation? – esskar Apr 19 '13 at 7:01
Could the current patent situation with ECC be a reason?… – Kaypro II Aug 30 '13 at 19:50
@KayproII not sure, says that patent is only on implementation technique not on the actual idea behind ECC! – esskar Sep 2 '13 at 7:55
See things that use curve25519 See things that use ed25519 I have a bunch of instructions on my site for secure ssh ciphers & if you use Debian google for 'Debian Jessie - backporting gnupg 2.1' (I can only post 2 links) – Stuart Jul 20 '15 at 20:13
up vote 21 down vote accepted

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.)

share|improve this answer
we don't have proof that any of the cryptographic algorithms that we employ is really robust against attacks What? How do we not have proof? We know discrete logarithm, integer factorization, etc. etc. are computationally difficult to solve. I don't understand how there is no proof. – Rell3oT Apr 19 '13 at 16:23
We have no proof that discrete logarithm or integer factorization are inherently difficult. It is just that we long searched for an efficient way to solve discrete logarithm or integer factorization, and our best algorithms so far are not very efficient. This in no way proves that efficient factoring algorithms cannot exist -- it just means that such algorithms, if they exist, are not very obvious. – Thomas Pornin Apr 19 '13 at 17:03
Oh okay. This makes sense then. If some mathematician discovers an algorithm to make these problems easy then our current asymmetric key algorithms will be quite useless. – Rell3oT Apr 19 '13 at 17:08

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

share|improve this answer
Curve25519 is also supported since 2.1.7 I think. Saw it today in 2.1.13 – Wilhelm Erasmus Jul 9 at 14:37

in GPG, for security, one would stay away from brainpool, and nist curves. edDSA, montgomery and edwards curves are fine. ed25519 is luckily being deployed without subrterfuge for now.

Although it is just for signing/certifying/authentication. Encryption will follow.

the mailing lists on are brilliant places to start, and checking as well.

Using ECC with folly implementation is worse than using even RSA.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.