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>
