4 ms·

You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cann

You need to generate a new one on key (it’s not actually generated and already on the key, but that’s a technical detail). The idea is that the private key cannot be leaked since it never leaves the key.

johnisgood 2y ago
Is there no way to use my existing one with either version / model? :(
- nine_k 2y ago
  No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
  - johnisgood 2y ago
    I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).
    - nine_k 2y ago
      1. A hardware key usually has no clock. But software, such as GPG, can set and check they key expiration date, and complain. For git, you usually have to have an SSH key for access, and a GPG key to sign commits, even though signing with an SSH key is possible by now. I keep signing with GPG, so that if my ssh key is rotated or revoked, my commits still remain signed. 2. If you lose a key, whatever its nature, you unenroll it where you have it enrolled. You better have some one-time codes set up, or another alternative method, like a password login to your VM via console.
      - johnisgood 2y ago
        Thank you for the answers! I use GPG to sign, too, and authenticate with SSH (but with my GPG key that has an A subkey through gpg-agent).

johnisgood 2y ago

Is there no way to use my existing one with either version / model? :(

nine_k 2y ago
No. The whole point of hardware keys is that the private key bytes are securely locked inside the key, with no way out (cannot steal) and no way in (cannot forge / tamper with). Reuse of an existing key for any reason after enrollment is not a good idea. A reluctance to just enroll another key may mean trouble with key rotation and revocation, and thus problematic security procedures. Key rotation should be fast, painless, and regular.
- johnisgood 2y ago
  I have two more questions. 1. Does it ever expire? 2. What would you do exactly if you were to lose the hardware key? Same thing as if you lost your id_ed25519 file? > Key rotation should be fast, painless, and regular. I agree. Right now I keep changing the expiry date of my GPG keys (once in a good while).
  - nine_k 2y ago
    1. A hardware key usually has no clock. But software, such as GPG, can set and check they key expiration date, and complain. For git, you usually have to have an SSH key for access, and a GPG key to sign commits, even though signing with an SSH key is possible by now. I keep signing with GPG, so that if my ssh key is rotated or revoked, my commits still remain signed. 2. If you lose a key, whatever its nature, you unenroll it where you have it enrolled. You better have some one-time codes set up, or another alternative method, like a password login to your VM via console.
    - johnisgood 2y ago
      Thank you for the answers! I use GPG to sign, too, and authenticate with SSH (but with my GPG key that has an A subkey through gpg-agent).