Announcing paperbackup.py to backup keys as QR codes on paper
Gerd v. Egidy
gerd.von.egidy at intra2net.com
Wed Feb 22 09:38:51 CET 2017
> > gpg2 --armor --export "User Name" >key.asc
> > gpg2 --armor --export-secret-key "User Name" >>key.asc
> > paperbackup.py key.asc
> this is a cool idea. however, it seems like you might be backing up
> more than most people would need. For most folks, their OpenPGP
> certificates (public keys) are stored on the public keyservers. Or at
> least their friends have a copy of them :)
> Even if you want the whole certificate, you've duplicated most of the
> material here -- just the data produced by --export-secret-key should be
> sufficient to reconstruct everything. Probably, putting less data in
> your qrcode backup will make the backup more robust during recovery..
You are right that this is probably more than strictly neccessary. But if you
look at my example output on github, a regular public and private key in
qrcodes and plain is just 9 pages.
If some of the qrcodes containing the public key could not be decoded during
recovery, it won't affect the codes of the private key. The user will just
have to remove the ascii armored remnants of the public key. So adding the
public key won't hurt.
paperbackup.py doesn't know or understand public or private keys, it just
cares about text files. So the user is always free to decide what parts to
> Are you aware of David Shaw's paperkey?
Yes, I have linked it in the README on github, section "Similar projects".
> This produces significantly less data (still in text form, though), so
> it could be combined with your approach to have a nice big, robust,
> scannable recovery mechanism.
Correct. But unless you want to backup hundreds of keys I don't think it is
necessary to think much about data reduction. It is just a few pages of paper
and printing and scanning them is just a matter of a few minutes.
This is the beauty of qrcodes in contrast to OCR and manually typing.
More information about the Gnupg-users