Evaluating switching from RSA to ECC when provisioning YubiKeys.

Noticed that when I run gpg --expert --full-generate-key and select “ECC (set your own capabilities)”, the “Toggle the encrypt capability” feature is not available (vs when using RSA).

I am trying to generate ECC master key from which I would like to derive signing, encryption and authentication sub-keys.

Why? Thanks for helping out!

  • To piggy-back on @user1686's answer, the subkeys are hierarchial with a YubiKey, so ensure the first three attribute subkeys are the keys you want to use in the S, E, and A slots (you can store as many subkeys as you want, but only the first one of each attribute [S, E, A] will be assigned to the YubiKey's slots). For example, I use the A slot for my SSH key, but since only the first A subkey can be used, I had to choose which key I wanted to use across all my SSH servers and ensure it was the first A subkey; AFAIK, there's no way around this, but if anyone knows a way, please let me know =]
    – JW0914
    Commented Jul 16, 2021 at 13:08
  • @JW0914: I've never tried this but I'm pretty sure you can explicitly select a subkey in --edit-key and use keytocard... Commented Jul 16, 2021 at 13:11

1 Answer 1


Subkeys are not derived from the master key. They are merely signed by the master key, but otherwise have no relationship to it – their capabilities and even algorithms do not need to match.

Indeed that's the whole point of subkeys in PGP. Originally it used a single RSA keypair for everything, but now there is a common saying among cryptography experts that the same key should never be used for different purposes, such as signing and encryption – so eventually the 'subkeys' feature was invented so that signing could be done using one RSA key and encryption using another.

(To some extent, even using the same signing key for network authentication and document certification is not a good idea – even though those are the same thing cryptographically, they're different policy-wise. The "PIV smartcard" mode in your Yubikey has explicitly separate keyslots for these purposes, because they have different PIN requirements.)

So while RSA keypairs in PGP can still have all capability bits at once (for legacy reasons), all other key types are explicitly treated as using different algorithms for signing and encryption – an "ECDSA" (19) or "EdDSA" (22) key can only sign/verify and an "ECDH" (18) key can only encrypt/decrypt. Something similar applies to DSA versus ElGamal.

And because the master key in PGP is used to certify both other people's keys and your own subkeys, it must be a signing-capable algorithm with the certify capability. For an EC key, this rules out the encryption-capable algorithms.

But as already mentioned, this does not affect subkeys in any way. Once you have the primary key generated, you can add subkeys with any algorithm (for example, even an old RSA primary key could have an Ed25519 signing subkey and a P256 authentication subkey).

  • Thanks so much for helping me make sense of all of this!
    – sunknudsen
    Commented Jul 16, 2021 at 13:04
  • So when creating ECC master key (with intention of signing subkeys), the only required capacity is “sign” and “authenticate” can be ignored, right? Asking because I do not see “certify” capacity in GnuPG 2.2.12. I am likely missing something.
    – sunknudsen
    Commented Jul 16, 2021 at 13:07
  • 1
    "certify" is not in the list because it's mandatory for the primary key -- so it is always set and you cannot turn it off. (Meanwhile, "sign" is specifically for signing messages/documents, not other keys, so it can be safely turned off if you prefer using a subkey for that.) Commented Jul 16, 2021 at 13:09
  • So when creating ECC master key, we do not need to toggle (enable) any capacity right? I was confused after following this very popular GnuPG/YubiKey (RSA) guide. My understand is that the same logic applies to RSA when one is not planning on using master key for anything else than managing subkeys.
    – sunknudsen
    Commented Jul 16, 2021 at 13:12
  • 1
    The goal is not to "toggle" capabilities. In the tutorial you linked to, the goal is to disable unwanted capabilities, and the "Toggle" menu item is just the mechanism for doing it. So you should be looking at which capabilities are shown in the "Current allowed" list – if the capability is enabled and the tutorial wants to disable it then yes, you should still toggle it off, but if e.g. encrypt was already disabled from the beginning, then it would be completely pointless to "toggle" it again. Commented Jul 16, 2021 at 13:24

You must log in to answer this question.

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