Recommendations: GPG, encryption, and multiple smartcards

GnuPG
,
1

Hello GPG Community,

I am trying to set up my primary GPG key, which I want to use for various purposes, including standard use cases like file/e-mail encryption and more niche features such as authentication when using SSH. Using the wiki, man pages, and other resources, like the infallible Stack Overflow, I created most of my desired setup. However, I encountered a problem which I could not solve so far. In short, my desired setup (and please tell me if you have suggestions on how to improve or where I might have made incorrect assumptions) is as follows:

I have three YubiKey 5s, two personal keys, and one from my workplace. I want to use these YubiKeys as OpenPGP smartcards. After some research, I settled on a primary certification key that does not expire and will be moved to an offline medium. Furthermore, I want to create three subkeys for signing, encrypting, and authenticating for each YubiKey. My reason for this is that these subkeys are generated on the device, and in case of loss or theft, I can revoke the three subkeys for the lost device instead of my entire key. Thus, my public key contains the primary certification key and three encryption, signing, and authentication keys for a total of 9 keys.

However, there is a catch. It seems the current implementation uses the “latest” encryption key from a public key rather than all, even if they are all valid and unexpired encryption keys. Thus requiring me to use a specific device rather than any of them. At first, I thought a workaround might be using the same subkeys on each device, but since GPG uses key stubs for smartcards, which are linked to the smartcards’ serial number this does not work either without reloading in some way. I have seen simply deleting these key stubs after plugging in the device or forcing a reload through gpg-agent.

Now, my main questions are: Have I missed something? And is the “transparent” use of multiple smartcards currently not possible? I am aware that I can force the use of a specific encryption key using the ! suffix, but this requires additional work and awareness from the sender. I have seen that GPG recently added Additional Decryption Subkeys (ADSK), but a subkey can’t be an encryption and ADSK key simultaneously. Thus, I have no method of signaling that a sender should use all of my encryption keys at once if possible.

I hope I haven’t overlooked anything and done all my due diligence. Maybe someone can offer a solution or confirm my suspicions.

Thank you for reading my post and kind regards :smiley: .

An example of such a setup is:

pub   ed25519 2025-04-19 [C] [ultimate]
      6C39 6098 DD7D 3912 12A1  D99C B6CD 986A 4558 97AD
uid           [ultimate] XXX
sub   ed25519 2025-04-19 [S] [expires: 2027-04-19]
      A921 D5ED 40E9 19FB AE03  3BA1 E2DE C941 5762 83ED
sub   cv25519 2025-04-19 [E] [expires: 2027-04-19]
      4B99 EBC7 94B5 F798 75A4  C43E 85B2 16D4 8E7A 959C
sub   ed25519 2025-04-19 [A] [expires: 2027-04-19]
      F75F 9207 FF22 D9BE B904  F980 9D65 9369 9386 AA82
sub   ed25519 2025-04-20 [S] [expires: 2027-04-20]
      B754 53E4 557B DFDC D93A  687B 2C8F E59C 5AFB FD29
sub   cv25519 2025-04-20 [E] [expires: 2027-04-20]
      EA64 6FCF 17F4 475F 79FB  5368 A70A 47A6 E415 FA9C
sub   ed25519 2025-04-20 [A] [expires: 2027-04-20]
      4F3B 36A4 F388 BAC4 7E5F  B800 7F1A 7EEE 4C6A 2AB8
sub   ed25519 2025-04-20 [S] [expires: 2027-04-20]
      3176 E3AE 9C55 F040 E027  7F3D DB93 0CEE FE3E ECEE
sub   cv25519 2025-04-20 [E] [expires: 2027-04-20]
      4C54 AD18 7796 3EC6 0C2A  F4E9 B378 70D5 6B3B D8B9
sub   ed25519 2025-04-20 [A] [expires: 2027-04-20]
      5A60 A007 3ECD 561E B094  DCF8 4E23 F2D1 EF95 40A8
2

Hi @skl27,

this is a pretty complicated setup already - and one that would take a bit to replicate and test.

I suggest to ask this on the Gnupg-users Info Page mailinglist and include the version of GnuPG that you are using.

It maybe possible that using several “smartcards” each with a different set of private key material for subkeys is not fully supported. It is a bit unusual. Maybe there is a simpler setup that will get you similar security properties form those that you are aiming at. So it cannot hurt to state your goals and considerations as well.

Best Regards,
Bernhard

3

This is a misconception. An ADSK subkey is an encryption subkey with an additional flag that it should be used as ADSK. Thereby signaling to gpg that in this case it should encrypt to that subkey additionally to the encryption subkey it would normally use.

Btw, have you checked out the blog artikel on ADSK?

It is required that the person encrypting the data uses a new enough version of gpg for this to work.

4

Hi @bernhard,

I know this setup is somewhat unusual, but it felt like making use of the hardware I already have would make sense especially since I plan on publishing this key and using it for a long time. Thus, I wanted to set this key up properly from the beginning and I am very much open to suggestions of a different setup :slight_smile: . While I have a basic and theoretical grasp of the concepts (read university courses, seminars, and whatever I read up in my free time) my actual practical knowledge and experience are quite limited.

My second reason for using a smartcard is being able to use simple PINs in combination with a lock-out rather than having to remember a truly secure password/-phrase.

I will try the mailing list as you suggested. By security considerations you mean my current setup and what I am trying to achieve? So something like:

Systems:

  • Linux Distro with very up-to-date GnuPG versions (currently gpg 2.4.7, libgcrypt 1.11.0)
  • Full Disk Encryption
  • I am the only user

Use-Cases by order of importance to me:

  • File encryption/signing to and from others
  • File encryption for backups in untrusted locations (small but important files)
  • E-mail using Thunderbird with an external agent
  • Signing commits and possibly packages for my distro
  • SSH authentication using gpg-agent as ssh-agent

Thank you for the quick reply and kind regards,

Sven

5

Hi @eebb,

I have read the article you pointed out. It was where I first learned of ADSK :slight_smile: . The gpg version (currently gpg 2.4.7, libgcrypt 1.11.0) is not a problem since my distro keeps very up-to-date as the package managing itself relies on gpg for core packages and maintainers. Additionally, I suspect that most of my use will take some time to pick up but I want to keep consistent in my key use and not switch very often other than rotating subkeys. I also hope that software like Thunderbird will soon support them.

My problem is that I wasn’t able to mark my encryption subkeys as ADSK (thus my assumption that encryption keys and ADSKs are somehow different). When I tried to edit my keys and add them as ADSK I got an error message somewhat like: “key already in keychain” and I couldn’t find another command to set the flag you speak of.
I had the idea of somehow “fabricating” a public key where I have a pure encryption subkey of the YubiKey I use most often and adding the other two as ADSK in the hope that software support would come along. Thus if someone uses older software and encrypts something to me I just have to use my primary key explicitly and someone using a newer version of gpg would be able to use all three encryption keys transparently. However, it felt like a very hacky solution and I wanted to reach out to see if someone had better ideas or plainly told me that what I was trying to do was rather stupid and I should just rely on a traditional setup with keys on the system.

Thank you for your quick answer :slight_smile:

6

Hi @skl27,

over the years, I’ve seen people doing too complicated setups, which later got a hassle for them without adding much to the security from the beginning.

So personally I often recommend to start with something less complicated. Like two crypto tokens, both with the same private key material and this material backed up somewhere (e.g. on paper) for revocations. But with default key and subkey settings. This is already somewhat complex.

At some point you would want to change your private key material anyway. This is going to be some work for you and for others (that have build trust on your old pubkeys).

A workflow I’ve seen is to use new encryption subkeys every two years (which you then need to transfer to your tokens and back up). And I use a signing subkey for 10 years and switch to a complete new key afterwards with some overlap.

The question is always: How high are your security requirements and how much effort do you want to put into defending against which attacks? It is not easy to say from the beginning. Often other attacks will much more likely so you (in theory) should spend more time hardening your systems and procedures against those. So a main criteria for building a security work I’d recommend is: Can you manage this easily for the years you want to run it?

Hope this gives you some ideas.

Regards,
Bernhard

1 Like