Hacker News Reader

Hacker News

Comment by johnisgood | Hacker News Reader

Parent Full thread

johnisgood

Yeah, that is why you should not [always (depends on your use case)] generate it on a YubiKey.

You need to have:

- an offline master private key backup (air-gapped)

- primary YubiKey (daily use)

- backup YubiKey (locked away)

- revocation certificate (separate storage) (it is your kill-switch)

Having a second YubiKey enrolled is the standard practice.

What people do wrong is:

- They generate directly on YubiKey

- They only use one device

- They do not create a revocation certificate

- They have no offline backups

You generate your GPG keys on a secured system, load the subkeys (not the master because it is not used for daily cryptography) into the YubiKeys, and then remove the secret keys from this system where you generated the keys.

View on HN

> Yeah, that is why you should not generate it on a YubiKey

No. You should ALWAYS generate on the Yubikey. That's the whole point.

Your backup is one (or more) other keys.

A lot of absolutes are being thrown around in the comments here, unfortunately. It really depends on your scenario.

Generating keys exclusively in (non-backup-able) secure hardware is great if your scenario readily supports multiple keys per server/domain you're authenticating in.

Creating an airgapped backup and loading that into a "daily driver" Yubikey marked as non-exportable can be perfectly fine if that's not the case and you don't want to notify the world every time you're adding or retiring a new Yubikey (for reasons other than key compromise).

Depends on your use case, and you will still have to generate your master key offline even if you want the subkeys generated directly on each YubiKey, which then you sign with the master key.

It is only slightly less secure if you pre-generate subkeys on an offline machine if you want identical subkeys on multiple devices (and if you want exact backups). Sometimes this is exactly what people want.

Ultimately it really depends on your use case.

BTW, please check the parent comments to which I responded.

PS. I think it would be useful for others if you elaborated on your statements (for educational purposes).

I can understand revocation for GPG, but is revocation ever used for SSH? I could understand it if SSH certificates are used, but honestly I've never encountered an org using SSH's cert system.

Well, OpenSSH has a built-in key revocation mechanism (KRL which is just SSH revocation), and there are SSH certificates (with a CA) and certificate revocation, and there is ad-hoc "revocation" by removing keys from the "authorized_keys" file.

If you use your GPG key for SSH, the servers that have your public key do not automatically know that your GPG key was revoked, and SSH authentication will proceed unless you remove the public key from the server OR the server uses an SSH CA/KRL model.

All in all, SSH supports real revocation, but it must be enforced by the server. It is different from GPG where revocation follows the key, not the server.

I have not used KRL myself, but I sort of know how it works. You can generate a new empty KRL, then add keys to revoke, and then to distribute the KRL to servers by configuring OpenSSH to use the KRL file, by adding "RevokedKeys /etc/ssh/revoked_keys.krl" to "/etc/ssh/sshd_config".

The pros of KRL is that they scale better than manual removal for multiple servers, and you can revoke entire CA ranges instead of individual keys if using SSH certificates which is recommended for large setups.

I hope I could clear some things up. Let me know if you have any questions though!

Does OpenSSH's `sshd` even support GPG key revocation? (Assuming you're talking about using the GnuPG card application of Yubikeys, since the newer "native" FIDO security key implementation of OpenSSH does not support importing existing keys to my knowledge.)

I elaborated on sshd + GPG key revocation here: https://news.ycombinator.com/item?id=46026415

Short answer is that it does not.

I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.

Do you have a good guide/video/write up on this?

I’ve been putting off remaking my GPG and SSH keys using a Yubikey.

This guide [1] mostly follows the practices the previous poster outlined.

[1] https://github.com/drduh/YubiKey-Guide

At https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#co..., these options are not the most secure one.

  personal-cipher-preferences CHACHA20 AES256 AES192
  personal-digest-preferences BLAKE2B SHA512 SHA384 SHA256
  personal-compress-preferences Uncompressed
  personal-aead-preferences OCB EAX
  default-preference-list BLAKE2B SHA512 SHA384 SHA256 CHACHA20 AES256 AES192 Uncompressed OCB EAX
  cert-digest-algo BLAKE2B
  s2k-digest-algo BLAKE2B
  s2k-cipher-algo CHACHA20
  s2k-count 65011712
  charset utf-8
  no-comments
  no-emit-version
  no-greeting
  keyid-format 0xlong
  list-options show-uid-validity
  verify-options show-uid-validity
  with-fingerprint
  require-cross-certification
  require-secmem
  no-symkey-cache
  armor
  use-agent
  throw-keyids
  weak-digest SHA1 RIPEMD160 MD5
  disable-cipher-algo 3DES CAST5 IDEA BLOWFISH TWOFISH CAMELLIA128 CAMELLIA192 CAMELLIA256
  disable-pubkey-algo RSA1024
  trust-model tofu+pgp
  keyserver hkps://keys.openpgp.org
  keyserver-options no-honor-keyserver-url
  keyserver-options include-revoked
  keyserver-options auto-key-retrieve
  force-mdc
  require-compliance
  compliance de-vs

These are the most secure options (correct me if I am wrong). The only drawback you may encounter is that you need GnuPG 2.3+, and some compatibility tradeoffs.

On second thought, you may want to remove this line:

  compliance de-vs

Because DE-VS only recognizes AES/3DES for ciphers and SHA-2 for digests; conflicts with CHACHA20 and BLAKE2B and will reject operations using these algorithms.

You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.

I know the difference, thank you for your concern.

Reply on news.ycombinator.com