Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.

▲

johnisgood an hour ago | parent | next [-]

Yeah, that is why you should not 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.

▲

eptcyka 5 minutes ago | parent | next [-]

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

▲

epistasis an hour ago | parent | prev [-]

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.

	▲	johnisgood 33 minutes ago \| parent [-]
		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!

▲

nothrabannosir 43 minutes ago | parent | prev | next [-]

Which makes yubikey impossible to use with geographically distributed backups. You need the backup available at all times for when you want to register with any new service.

This is why you should use a device which allows exporting the seed, like e.g. multi purpose hardware crypto wallets.

▲

epistasis 36 minutes ago | parent [-]

Are you talking about SSH or a different setting?

With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.

▲

nothrabannosir 32 minutes ago | parent [-]

No I got distracted by the word yubikey. Arguably not the same subject. :)

	▲	epistasis 27 minutes ago \| parent [-]
		Nonetheless I'm glad to hear about it. I don't yet use YubiKeys for FIDO, because I was concerned a bit about this enrollment process, and hadn't bothered to figure out what others do.

▲

an hour ago | parent | prev [-]

[deleted]