Comment by xvector | Hacker News Reader

Comment by xvector | Hacker News Reader

I disagree with the recommended key generation flow in this guide. I think the private key should be generated on-device, so it can never be extracted without faulting the YubiKey hardware.

I also disagree with the idea of backing up the private key. Generating secure passwords is hard and it is infeasible to ask people to use diceware to generate and store their secure backup. And if you aren't doing backups you might as well generate the key on device. For the purpose of revocation, you can keep a signed revocation certificate around in the event you lose your key.

This makes the guide much simpler, as you don't have to spin up a live airgapped system with secure boot for each employee's key generation. There's no need to have a complicated backup flow either.

---

YubiKeys in general are problematic as they don't have a display that can show the action being taken, e.g. a compromised host could display one thing while the user is signing/encrypting another. This isn't a problem in modern crypto hardware wallets, which have displays that show precisely what is being signed, to mitigate this exact threat model.

> I also disagree with the idea of backing up the private key.

You should have secure copies of your master key. Especially if you've invested time in building up your web of trust. Backing up encryption keys is also useful. If they're lost, data cannot be decrypted later. Signing keys are the only ones which are completely expendable.

Creating a paperkey and storing it in a physical safe is ideal. That way you can keep your master key offline until needed and use subkeys for daily use.

You can encode it as a QR code:

  gpg --export-secret-key $KEY | paperkey --output-type raw | qrencode --8bit --output secret.png

And easily restore it later with zbar:

  zbarimg --raw --oneshot -Sbinary secret.png | paperkey --pubring public.asc | gpg --import
  zbarcam --raw --oneshot -Sbinary | paperkey --pubring public.asc | gpg --import

A vast majority of people should create paperkeys. I will just note that if one creates a paperkey by printing it out, they are transmitting their secret key over the network to likely an internet-connected printer that also sometimes stores documents in its cache for a while.

>You should have secure copies of your master key. Especially if you've invested time in building up your web of trust. Backing up encryption keys is also useful. If they're lost, data cannot be decrypted later. Signing keys are the only ones which are completely expendable.

Where can I read to how to do that?

The paperkey documentation.

https://www.jabberwocky.com/software/paperkey/

https://wiki.archlinux.org/title/Paperkey

The paperkey tool will produce a human-readable text file that you can print out. I found that to be inconvenient and settled on QR codes instead. They're ubiquitous, machine-readable and have built-in error correction.

I did exactly this minus the backup key. Problem is that the backup is nearly meaningless since it is just a second totally different key. For most services that is fine as they allow to setup multiple keys (GitHub, Gitlab, etc). But some services don’t. My first Yubikey is partially broken. I only wait for the day the usb connector breaks out. I already have new yubikeys and it would be awesome to just put the same key on them to have no fuss.

I’m at the moment between keys. I tried to use the new SSH keys which resides on the FIDO key. Problem is that most services I wanted it to use for don’t understand them. Most prominently Ubuntu LTS18.4 because of no official support for OpenSSH 8.2. So I use my old key with an ssh key derived from gnupg and a new one with resident ssh key.

Do you have another one to recommend looking at?

(I already own a Ledger Nano X and a Trezor in case that’s what you mean with “crypto device” and find the GPG experience insufficient).

Unfortunately it does not look like the security key industry has caught up to the hardware wallet industry.

Unlike a YubiKey, the screen on both Trezor and Ledger mitigate the confused deputy/phishing attack for the purposes of FIDO U2F. I'd recommend them with usage for U2F, specifically the Ledger if you're interested in better hardware security at the expense of open-source.

I’ve tried both. Unfortunately the U2F as well as the PGP are clearly afterthoughts on these devices - the key management is lacking (doesn’t tie in well with the recovery phrase otherwise used for crypto assets) and the UX is cumbersome.

I can overlook the UX issues when it’s a matter of 1-10 average signs per day and not 100s, like I have with PGP+U2F. I guess they’re all right as backup devices.

The new Nitrokeys look interesting (and not yet available) but I agree, something is missing in the market here.

> and not 100s, like I have with PGP+U2F

I'm really interested to hear what you're doing that gives you 100s of signatures a day (or decrypts?)

I have been searching for an openpgp card replacement but I use one with a hardware pinpad, I can't imagine entering my pin 100s of times a day!

>This isn't a problem in modern crypto hardware wallets

Which ones?

Ledger and Trezor, I talk more about them in other replies.

Is there a better device for GPG signatures then?

Unfortunately I don't think anyone has done this yet.

I think solving the lack-of-display problem is far easier for FIDO/TOTP than GPG, as with GPG you could be signing arbitrary content that is difficult to validate on a small screen.

But FIDO/TOTP data are more structured and can be coerced into being displayed on the device's screen, as shown in this video [1].

[1]: https://youtu.be/KPmf9mbYKuo?t=163

Reply on news.ycombinator.com