26

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?`
Community
  • 1
esskar
  • 629
  • 1
  • 5
  • 12
  • 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. –  Apr 19 '13 at 01:57
  • 2
    @Rell3oT do you know of any reason why it hasn't found its way to the gnupg offical implementation? – esskar Apr 19 '13 at 07:01
  • 1
    Could the current patent situation with ECC be a reason? http://www.technologyreview.com/view/518476/encryption-patents-could-be-blackberrys-biggest-asset/ – Kaypro II Aug 30 '13 at 19:50
  • 1
    @KayproII not sure, http://en.wikipedia.org/wiki/ECC_patents says that patent is only on implementation technique not on the actual idea behind ECC! – esskar Sep 02 '13 at 07:55
  • 1
    See [things that use `curve25519`](http://ianix.com/pub/curve25519-deployment.html) See [things that use `ed25519`](http://ianix.com/pub/ed25519-deployment.html) 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 Cardall Jul 20 '15 at 20:13
  • I wouldn't trust anything [NIST pushes](https://www.scientificamerican.com/article/nsa-nist-encryption-scandal/). – Chris Smith Feb 09 '21 at 00:11

3 Answers3

26

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

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    `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. –  Apr 19 '13 at 16:23
  • 27
    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
  • 3
    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. –  Apr 19 '13 at 17:08
  • 2
    Well, given that mathematics only matured in the past 300 years, the stated “*2500 years* of underlying mathematics” is a bit misleading: As with Fermat’s Last Theorem, I doubt that anyone will come up with a solution to integer factorisation that would have been even possible to dream of before 18th century mathematics came along. The confidence I have in the hardness of these problems lies more in the quality rather than in the quantity of previous attempts at it. Both problems have withstood the “same” arsenal of modern higher mathematics for seventy years. – k.stm Mar 11 '17 at 10:53
9

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

Adrian
  • 91
  • 1
  • 1
  • Curve25519 is also supported since 2.1.7 I think. Saw it today in 2.1.13 – Wilhelm Erasmus Jul 09 '16 at 14:37
  • 2
    @WilhelmErasmus – Ed25519 was [mentioned as](http://www.gossamer-threads.com/lists/gnupg/users/69471) supported in 2.1.1. The [official GnuPG 2.1 release notes](https://www.gnupg.org/faq/whats-new-in-2.1.html) list GnuPG 2.1.0 as supporting Ed25519 for signing (I'm not sure about encrypting), though this was ahead of the OpenPGP standardization of Ed25519. – Adam Katz Jan 05 '17 at 02:43
  • Although GPG already supports it, EdDSA is still on its way to the standard. Latest status can be found at [IETF datatracker](https://datatracker.ietf.org/doc/draft-ietf-openpgp-rfc4880bis/). – Franklin Yu Sep 05 '19 at 14:23
6

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 ietf.org are brilliant places to start, and checking cryp.to as well.

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

Njomsky
  • 61
  • 1
  • 2