I've created a PGP key set which consists of the following:

  • A master RSA key with only signing capabilities, stored offline.
    • Multiple OpenPGP cards, each with three RSA keys:
      1. An encryption key
      2. A signing key
      3. An authentication key for SSH

My reasoning behind making it this way is so that if a single hardware card gets stolen, I can revoke all of its certificates in a way that doesn't "damage" my remaining infrastructure. (Except, of course, that I now need to re-encrypt my encrypted data to exclude this key and that I need to recreate long-lasting signatures with a different signature subkey, but these things don't damage my identity: they're just really inconvenient.)

Granted, multiple encryption keys is not the best idea, but I'm particularly concerned with encrypting and decrypting backup files and not emails as much. I'm not sure if there's a way for an emailing user to have their emails encrypted to all three of my encryption keys at once, but it's not the end of the world (though really inconvenient) if it's only encrypted to one encryption key.

The problem I'm currently facing involves trying to setup a LUKS boot with a GPG encrypted keyfile. My current setup works, but it only allows decryption with one of the cards. My public and secret keyrings look fine, the secret keyring contains stubs for all of the smart cards. If I try decrypting with another one of the cards, it chokes and fails, prompting me to insert the "right" card.

My key file is encrypted like this:

gpg --output /keyfile.gpg --encrypt --recipient $MASTER_KEY_ID \
    --encrypt-to $ENC_SUBKEY_1! --encrypt-to $ENC_SUBKEY_2! \
    --encrypt-to $ENC_SUBKEY_3!

Note how I'm using ! to force it to encrypt for these subkeys specifically. On boot with cryptsetup, I see the following message if I have a different card inserted:

gpg: error reading application data
gpg: decryption failed: secret key not available
cryptsetup: cryptsetup failed, bad password or options?

If I use the card containing $ENC_SUBKEY_1, decryption works and the OS boots.

My key script is fairly close to the one provided by cryptsetup:

if ! /lib/cryptsetup/askpass "Enter passphrase for key $1: " \
    /usr/bin/gpg -q --batch --no-random-seed-file --homedir /lib/cryptsetup/gpg \
        --ignore-valid-from --ignore-time-conflict --passphrase-fd 0 --decrypt $1; then
    return 1

return 0

If I do the same kind of encryption on a file in my running operating system, I'll get an interesting output when I try decrypting with a key other than the first one passed as --encrypt-to:

Please remove the current card and insert the one with serial number:
Hit return when ready or enter 'c' to cancel

If I hit c up to twice, it'll eventually "find" the right key and decrypt the file. Presumably because it's in --batch mode on boot, it won't prompt and will instead just fail.

Is there a way to bypass this problem? Is there a way I can tell GPG to just keep trying until nothing at all works? ie: key for card 1 can decrypt; card 1 not present; key for card 2 can decrypt; card not present; key for card 3 can decrypt; card present; decrypt.

2 Answers 2


The problem is, that "stub" keys for all of the three cards are stored in your computer, and GnuPG is trying all of them.

Sadly, I'm not aware of an option to define a fixed decryption subkey, skimming through GnuPG's man page also did not reveal any.

As far as I see, the only option you have would be to remove all but the currently used encryption subkey from the keychain, and switching keychains if necessary. Be aware that before GnuPG 2.1, merging subkeys is a pain, so be sure to keep a keyring around containing all subkeys.

  • The logic I'm looking for is to have GnuPG first scan which keys that the file was encrypted for, then scan the presence of all secret keys available (first physical and then smart cards), and then try decrypting using the available (present) secret key. If that fails, then try the other ones. This seems like fairly consistent logic that shouldn't result in anything supremely illogical. Someone with an alternative setup in which they have multiple identities with one encryption key per identity would have the same problem. Commented Jun 8, 2015 at 18:58
  • I suppose I could modify my decryption script to just have GPG interface directly with stdin from the user, but I'm not sure what I'm getting into with that. As I'll likely have the file encrypted additionally for another identity altogether (with more subkeys), it'll be a painful process but it should probably work. Commented Jun 8, 2015 at 21:07
  • 2
    This surely is a reasonable thing to have -- but it seems it is not implemented. GnuPG is free software, you could simply implement such a feature. ;) I'd guess for such specifics you'd better ask on the GnuPG mailing list and possibly open a bug report containing a feature request (given there is no way to achieve the behavior you'd like to see).
    – Jens Erat
    Commented Jun 8, 2015 at 21:08

The canonical way seems to be to have one and only active encryption key. Quoting the manual:

Finally, it only makes sense to have one valid encryption subkey on a keyring. There is no additional security gained by having two or more active subkeys. There may of course be any number of expired keys on a keyring so that documents encrypted in the past may still be decrypted, but only one subkey needs to be active at any given time.

There's also a command to disable currently unused keys.

Otherwise put, the right course of action is to disable and/or archive all other keys, possibly keeping the only one encryption key on all cards.

You must log in to answer this question.

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