Announcing paperbackup.py to backup keys as QR codes on paper

[Gerd v. Egidy]

Hi Daniel,

> > 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 
back up.

> Are you aware of David Shaw's paperkey?
> 
>   http://www.jabberwocky.com/software/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.

Kind regards,

Gerd