I'm wondering if "WE ARE ALL DOING IT WRONG"?

[iandstanley]

We create our master key offline on TailsOS or whatever. Then we create a series of subkeys. Then we back it all up. And then we run keytocard in each of our sub keys

If we get an exposure of our signing key: we load up TailsOS and restore our master key backup, expire the old signing key, create a new signing key. Recreate the public key. Back everything up again. Publish the public key.

Sounds familiar right?

But our daily use subkeys never leave the Yubikey!

We only need the master key private key to void the exposed signing key. Right?

Then why do we generate the subkeys on disk then keytocard them?

Wouldn't it be better to generate the subkeys on the Yubikey and never have them outside the Yubikey?

Well we can.

---

Needing to check in something I looking into the rather tediously written GNU Privacy Guide manual. I know RTFM abut I don't know anybody personally who has read through this guide preferring to use the many good webpages and guides like this to get enough information.

I came across the sub command "addcardkey" (--edit-key) and it got me thinking.

I think the whole industry has chosen keytocard as a misunderstanding of how GPG is supposed to operate with Yubikeys/Smartcards.

I believe that the keytocard option was designed to migrate a users existing subkey to their brand new Yubikey.

For new subkeys they should be generated on card using the "addcardkey" subcommand.

The addcardkey subcommand generates the new key directly in the card and adds them to the master key specified in the --editkey option on the command line. The subkey never hits spinning rust or silicon.

$ gpg --edit-key $KEYID

Command> addcardkey Please select the type of key to generate: (1) Signature key (2) Encryption key (3) Authentication key Your selection? 3 gpg: 3 Admin PIN attempts remaining before card is permanently locked

Admin PIN:

The whole tech discussion on gpg just appears to copy the previous persons post or refers to what has turned out to be the unofficial defacto standard (DrDuh's guide) or some simplified version of this.

But I have never seen a reference back to the original GPG manual which has a section on this very thing. I've been using PGP and GNUPG since they came out and somehow missed this until a few weeks ago despite using Yubikeys all the time.

---

QUESTION: Should we be propagating this apparently wrong (but works) method in a most quoted public document or should we aim at correcting the most influential GnuPG/Yubikey source on the internet?

Maybe some of us with a. Spare Yubikey could try this out:

1. Create your basic master key.

2. Create your subkeys using --edit-key and the addcardkey subcommand

3. Revoke a subkey and regen it with addcardkey

4. Let us know what you think below.

I just can't get over the thought that either the whole industry is using GPG in the way the tool was not intended or I am missing something.

---

REFERENCES

. (DrDuh's guide)

https://www.gnupg.org/howtos/card-howto/en/ch05s02.html

https://we.riseup.net/debian/using-the-openpgp-card-with-subkeys

[iandstanley]

Trying out this subcommand:

I had some time tonight and dug out a spare Yubikey Neo to give this a try

$ gpg --full-gen-key --expert gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want: < CUT > (8) RSA (set your own capabilities) < CUT > Your selection? 8

Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt < CUT > Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Certify Your selection? q

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (3072) 2048 Requested keysize is 2048 bits Please specify how long the key should be valid. < CUT > Key is valid for? (0) 1d Key expires at Wed 15 Jun 2022 21:36:01 UTC Is this correct? (y/N) y

GnuPG needs to construct a user ID to identify your key.

Real name: demo Name must be at least 5 characters long Real name: demos Email address: [email protected] Comment: You selected this USER-ID: "demos [email protected]"

< CUT > gpg: key 0x22F9D75820061630 marked as ultimately trusted gpg: directory '/home/amnesia/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/home/amnesia/.gnupg/openpgp-revocs.d/D2571976987566A719BF5FBD22F9D75820061630.rev' public and secret key created and signed.

pub rsa2048/0x22F9D75820061630 2022-06-14 [C] [expires: 2022-06-15] Key fingerprint = D257 1976 9875 66A7 19BF 5FBD 22F9 D758 2006 1630 uid demos [email protected]

$ gpg -K gpg: checking the trustdb gpg: marginals needed: 3 completes needed: 1 trust model: pgp gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2022-06-15 /home/amnesia/.gnupg/pubring.kbx

sec rsa2048/0x22F9D75820061630 2022-06-14 [C] [expires: 2022-06-15] Key fingerprint = D257 1976 9875 66A7 19BF 5FBD 22F9 D758 2006 1630 uid [ultimate] demos [email protected]

$ gpg --edit-key [email protected] gpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

sec rsa2048/0x22F9D75820061630 created: 2022-06-14 expires: 2022-06-15 usage: C
trust: ultimate validity: ultimate [ultimate] (1). demos [email protected]

**gpg> addcardkey Signature key ....: [none] Encryption key....: [none] Authentication key: [none]

Please select the type of key to generate: (1) Signature key (2) Encryption key (3) Authentication key Your selection? 1** Please specify how long the key should be valid. < CUT > Key is valid for? (0) 1d Key expires at Wed 15 Jun 2022 21:38:06 UTC Is this correct? (y/N) y Really create? (y/N) y

sec rsa2048/0x22F9D75820061630 created: 2022-06-14 expires: 2022-06-15 usage: C
trust: ultimate validity: ultimate ssb rsa2048/0xF041306F867E9354 created: 2022-06-14 expires: 2022-06-15 usage: S
card-no: 0006 06518268 [ultimate] (1). demos [email protected]

[charltonstanley]

Although I'm not a security expert you make a good point, and you're right, it is more secure to addcardkey since the private keys would never leave the yubikey, BUT, it makes recovery harder/impossible. What happens if your yubikey is stolen or lost? What happens if it snaps off inside the usb port because you forgot to pull it out before you shoved your laptop into your backpack? As I understand it, you would be effectively "up a creek without a paddle" and would be unable to decrypt anything you had previously encrypted with the subkeys stored on the yubikey. Additionally, new subkeys from the same master key wouldn't allow you to decrypt your items either. For me personally, this is a "hard pass"; I'll glady absorb the risk of having a backup set of keys on a drive in my safe for future use. Per the guide, I think backing up the keys stored on disk before running keytocard is the best option; at least this way you could recover from an (albeit unlikely) disaster scenario.

[smlx]

I think generating keys on the card is the correct approach. Then you just need to encrypt everything with two subkeys - an emergency disaster-recovery key stored on disk with a strong passphrase, and the one on the Yubikey for everyday use.

[iandstanley]

Agreed.

I bought a secondary Yubikey just for my backup encryption key and all my scripts are setup for dual encryption.

This secondary key is kept secure and never leaves it’s location

Somebody else mentioned what if I lose the Yubikey with the encryption subkey.

My preference would be expire the subkey on the lost subkey and replace asap. Some may be bothered with being able to access old emails but I tend to either pdf important emails (& encrypt separately) or just delete it.

On 27 Jun 2022, at 11:58, Scott Leggett @.***> wrote:

 I think generating keys on the card is the correct approach. Then you just need to encrypt everything with two subkeys - an emergency disaster-recovery key stored on disk with a strong passphrase, and the one on the Yubikey for everyday use.

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.

[bhdicaire]

Thanks for the research, you should publish a blog about it!

You can have multiple signature sub keys but only one encryption subkey among your Yubikeys.

You explained well why you can live with that setup and I respect that.

This is not my case, and I'll continue to generate my subkeys on a live system.

[drduh]

One of the original motivations behind not generating keys on the card was https://www.yubico.com/support/issue-rating-system/security-advisories/ysa-2017-01/

Is there any material difference in the crypto handling generating keys directly on the card versus the OS?

[drduh]

We welcome any additional research, citations or alternative solutions to key generation and handling strategies. Please send a PR when you're ready to contribute!