8 ms·

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

by comprev 11mo ago

deleted 11mo ago
[deleted]
johnisgood 11mo ago
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.
- epistasis 11mo ago
  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 11mo ago
    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!
- eptcyka 11mo ago
  You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
  - johnisgood 11mo ago
    I know the difference, thank you for your concern.
- traceroute66 11mo ago
  > 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.
  - johnisgood 11mo ago
    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).
  - lxgr 11mo ago
    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).
- doublepg23 11mo ago
  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.
  - atrettel 11mo ago
    This guide [1] mostly follows the practices the previous poster outlined. [1] https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide
    - johnisgood 10mo ago
      At https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#configuration 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.
      - johnisgood 10mo ago
        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.
- lxgr 11mo ago
  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.)
  - johnisgood 10mo ago
    I elaborated on sshd + GPG key revocation here: https://news.ycombinator.com/item?id=46026415 https://news.ycombinator.com/item?id=46026415 Short answer is that it does not.
- wink 10mo ago
  I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.
nothrabannosir 11mo ago
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 11mo ago
  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 11mo ago
    No I got distracted by the word yubikey. Arguably not the same subject. :)
    - epistasis 11mo ago
      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.
- traceroute66 11mo ago
  > Which makes yubikey impossible to use with geographically distributed backups. Huh ? You do know you can wrap a symmetric key with multiple asymmetric keys, right ?
- Nextgrid 11mo ago
  This is true for passkeys/webauthn/u2f, which is why it’s trash and a completely flawed and not fit for purpose standard (of course the primary purpose is vendor lock-in, not reliable and disaster-proof authentication). But SSH allows you to export the public key and then you can enroll it on as many hosts as you want without needing access to the private key, so the backup key can remain in a safe, ideally forever as you should never need it.

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

by comprev 11mo ago

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

deleted 11mo ago

[deleted]

johnisgood 11mo ago

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.

epistasis 11mo ago
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 11mo ago
  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!
eptcyka 11mo ago
You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
- johnisgood 11mo ago
  I know the difference, thank you for your concern.
traceroute66 11mo ago
> 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.
- johnisgood 11mo ago
  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).
- lxgr 11mo ago
  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).
doublepg23 11mo ago
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.
- atrettel 11mo ago
  This guide [1] mostly follows the practices the previous poster outlined. [1] https://github.com/drduh/YubiKey-Guide https://github.com/drduh/YubiKey-Guide
  - johnisgood 10mo ago
    At https://github.com/drduh/YubiKey-Guide?tab=readme-ov-file#configuration 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.
    - johnisgood 10mo ago
      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.
lxgr 11mo ago
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.)
- johnisgood 10mo ago
  I elaborated on sshd + GPG key revocation here: https://news.ycombinator.com/item?id=46026415 https://news.ycombinator.com/item?id=46026415 Short answer is that it does not.
wink 10mo ago
I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.

nothrabannosir 11mo ago

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 11mo ago
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 11mo ago
  No I got distracted by the word yubikey. Arguably not the same subject. :)
  - epistasis 11mo ago
    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.
traceroute66 11mo ago
> Which makes yubikey impossible to use with geographically distributed backups. Huh ? You do know you can wrap a symmetric key with multiple asymmetric keys, right ?
Nextgrid 11mo ago
This is true for passkeys/webauthn/u2f, which is why it’s trash and a completely flawed and not fit for purpose standard (of course the primary purpose is vendor lock-in, not reliable and disaster-proof authentication). But SSH allows you to export the public key and then you can enroll it on as many hosts as you want without needing access to the private key, so the backup key can remain in a safe, ideally forever as you should never need it.