I want to generate a key pair with gpg2 2.1.11 and libgcrypt 1.6.5.

I use the command gpg2 --expert --full-key-gen. This allows me to choose an ECC:

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) ECC and ECC
  (10) ECC (sign only)
  (11) ECC (set your own capabilities)

I choose (9) and then it asks me which ECC I want to use:

Please select which elliptic curve you want:
   (2) NIST P-256
   (3) NIST P-384
   (4) NIST P-521
   (5) Brainpool P-256
   (6) Brainpool P-384
   (7) Brainpool P-512
Your selection?

Since I do not know which one is safe and not designed to be broken, I searched the internet and found: https://safecurves.cr.yp.to Now I do not know whether that page is trustworthy, but I also don't know where else a good source of information on this is.

Assuming the page is right and trustworthy, there seems to be not a single safe curve offered to me by GPG. Am I screwed now and damned to using an unsafe one, or is there a better source of information regarding this?

  • 4
    If you do not have a semi-rational reason for any of those it does not matter which one you chose. The security of your key, computer or pgp depends on so many other factors, those curves are all prettty much fine. If you want to show off use the larger numbers and if you distrusted the US go with the brainpool curves.
    – eckes
    May 24, 2017 at 19:18
  • @eckes Good points. I mainly do it out of principle. May 24, 2017 at 19:20
  • 5
    See here to get experimental support for the DJB curve: gniibe.org/memo/software/gpg/keygen-25519.html It is only specified in a OpenPGP draft. Best compatibility you get with NIST P-256 which is the only mandatory curve.
    – eckes
    May 24, 2017 at 19:42
  • @eckes Thanks. I have some questions though regarding what you wrote: What does mandatory mean? Mandatory for other programs to implement a standard of ECC? Whose standard is using something that NIST cooked up? I'd feel much better about it, if it weren't done in secret with the possibility of a secret key already being in the hands of NIST. In terms of security a precaution would demand choosing something else. May 25, 2017 at 9:45
  • The curves for PGP are defined in RFC 6637 from 2012. tools.ietf.org/html/rfc6637 It only contains the NIST curves. In the upcoming draft revision there is also Ed (most likely because of the bad rep the NIST curves got in the past, but also because of newer cryptographic methods) OpenPGP is generally very unmodern crypto.
    – eckes
    May 25, 2017 at 13:23

1 Answer 1


First, the options for generating a key with gpg provide you an option for creating your Master (certify) key at the same time as an encryption subkey. These are the options for (1), (2), and (9). Otherwise, you are creating one key and setting the capabilities on it.

You need to consider the trade-offs of modern cryptosuites and the software that supports them. Most GPG keys today are still using a root RSA key in order to maintain backwards compatibility with client software that does not yet support ECC. I have yet to see a smartcard or a secure element that offers Ed25519 curves. If you are using an HSM you are probably still restricted to NIST curves, and P-256 at that.

Of the ECC curves, the NIST curves have the most support. [Note: You can read this question to understand the concern around NIST parameters: https://crypto.stackexchange.com/questions/10263/should-we-trust-the-nist-recommended-ecc-parameters]

If I were using smartcards, I would use NIST curves with the largest key size the smartcard would allow. If I were not using smartcards, I would use an Ed25519 curve.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .