Long Term Key Management With Hardware Tokens

Brandon Anderson brandon753.ba at gmail.com
Tue Jun 22 20:47:45 CEST 2021

>> Many tutorials, examples, and articles that are talking about using 
>> Yubikeys and smartcards currently suggest making paper backups of the 
>> encryption key so you can add it to new devices if needed. But this, at 
>> least to me, feels like it's significantly reducing the value of 
>> using secure hardware like smartcards in the first place. Having the 
>> keys only ever exist on secure hardware, including the backups, would 
>> make this unnecessary.
> The disadvantage of only ever storing secret key material on a finite 
> number of secure hardware devices is that all such devices have a 
> lifetime, and once they're all dead your information is gone. You'll 
> still find yourself re-encrypting all your data to a new encryption 
> (sub)key when you get down to your last working hardware device.
> Having a non-secure offline backup does not negate all the advantages 
> of secure hardware. It depends on the threat model of course, but 
> *most* people are much more likely to have their laptop compromised 
> remotely than have their safe cracked and the paper backup stolen.
I agree that for most people having a paper backup stolen is unlikely, 
but then again, most people are not using GPG, to begin with, let alone 
GPG with smartcards or security tokens. There are several security 
concerns which having retirement keyslots can address. They can also 
improve the user experience as you won't have to air-gap a machine to 
view old records with revoked keys. All in all, it's about providing the 
option of having only security token access, not requiring it. I would 
expect any smartcard stored in a safe and only used infrequently during 
key changes and the occasional old record decryptions to last well over 
a decade.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0x255837AEF812E87E.asc
Type: application/pgp-keys
Size: 9076 bytes
Desc: OpenPGP public key
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210622/f9d46680/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20210622/f9d46680/attachment.sig>

More information about the Gnupg-users mailing list