... | ... | @@ -186,6 +186,39 @@ protocol for non-TPO hosts, you may add this at the end of `~./ssh/config`: |
|
|
IdentityAgent /dev/null
|
|
|
IdentityFile ~/.ssh/id_ed25519_sk
|
|
|
|
|
|
## OpenPGP operations
|
|
|
|
|
|
YubiKeys can also be used for general operation with OpenPGP,
|
|
|
regardless of purpose. For signatures, the operation is relatively
|
|
|
similar to the [SSH guide above](#ssh-authentication-in-openpgp-mode), except there's no need to do any
|
|
|
SSH-specific configuration.
|
|
|
|
|
|
### Special considerations for storing encryption keys
|
|
|
|
|
|
For *encryption* keys, however, special care need to be taken as the
|
|
|
loss of a YubiKey could be catastrophic: in such a case, while the key
|
|
|
can be revoked, that doesn't allow the operator to recover past
|
|
|
material encrypted with the key.
|
|
|
|
|
|
Encryption keys, therefore, must *not* be generated on the YubiKey as
|
|
|
they *MUST* be backed up. They therefore *MUST* be generated on
|
|
|
another device.
|
|
|
|
|
|
The general strategy here is to have three copies of the encryption
|
|
|
key:
|
|
|
|
|
|
1. `main key`: a first YubiKey used for daily operation
|
|
|
2. `backup key`: a *second* YubiKey available as a backup
|
|
|
3. `backup disk`: a copy of the encryption key material stored on a
|
|
|
normal disk, encrypted with itself
|
|
|
|
|
|
The rationale here is that if the `main key` is lost, the `backup key`
|
|
|
and `backup disk` can be *combined* to create a *new* `main key`.
|
|
|
|
|
|
If the `backup disk` did not exist, it would be impossible to recreate
|
|
|
a new `main key` and, when the `backup key` is eventually lost or
|
|
|
destroyed, the encrypted contents will not be readable anymore.
|
|
|
|
|
|
## FAQ
|
|
|
|
|
|
### I don't have usb-c in my laptop, would i need an adaptor then?
|
... | ... | |