On 22/02/17 16:10, Thomas Jarosch wrote: > When I think about long term storage, I'd rather rely on the full data > instead of a snippet of the openpgp packets.
I understand that. However, let me point out that any errors parsing will only occur while *creating* a backup with paperkey. Once it succesfully parses the data, the result can be used without the program, it is stand-alone and complete. No further "parsing errors" can occur. Rejoining the private key can be done by hand. Could you share a bit more details about the error you encountered? If it is a problem with paperkey, I think we (as a community) would like to know about it and hopefully fix it. > The argument about re-downloading the public key from the keyservers is valid > though, but for the secret key a full backup is preferred in our use case. All public data can be scattered all over the world and the internet, and backed up and replicated in all manner of forms for resiliency. In theory this goes for a private key with a good passphrase as well, but that moves the point of failure to remembering the passphrase. paperkey however can be used without a passphrase, and the result should be guarded really well, unlike all the public data. I'm not trying to convince you to do something differently than you do now, I'm just trying to make the picture more complete. However, it seems your solution to your use case depends on there being few signatures on a key, as evidenced by my key needing 104 pages (that's without the unnecessary duplication that resulted in the 208 pages I mentioned earlier). I would not enjoy the amount of room this book occupies in my safe, or scanning it. > It's easy for the user to skip the public key backup. Hmmmmm....... once we have export-minimal for --export-secret-key :-). > Also if the QR code scanning ever fails: There is base64 encoded text output > at the end, too. That could be OCRed or typed in by hand if ever needed. > (we use paperbackup.py just as additional backup) You might consider using a font designed for OCR rather than the current font. Additionally, base64 has look-alike characters, and the only checksum is for the whole key. So if it says "checksum failed" you've only learned that factoid. A checksum per line would be better, so you can say "checksum failed in line n". > You can even use paperbackup.py to back up your ssh key :) Yep. But if you trust GnuPG, and you have a paper backup of your OpenPGP key, you could encrypt a copy of your SSH key with your OpenPGP key and publish the encrypted file. Then as long as you have a paper backup of your OpenPGP encryption subkey, you can just fetch and decrypt the SSH key. This by the way goes for any piece of data, no matter how large, including all the videos you shot of your children while they grew up and would really dread to lose. Just encrypt them, back them up with several backup providers online, and as long as your paper backup of your OpenPGP key survives, so do the videos. It might even provide that little extra motivation to be extra sure the backup of your OpenPGP key can be depended on, now that you really do depend on it for something you care deeply about! ;-D Cheers, Peter. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
