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

[Peter Lebbing]

Hello Gerd!

Thank you for sharing your program with the world! I'm sure it will be
useful.

On 22/02/17 09:38, Gerd v. Egidy wrote:
> 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. 

I beg to differ. Following your instructions, my PDF is 208 pages long!

The certificate (aka public key) includes all signatures, all the data
on the keyserver. It's data you don't really need to back up since it is
public, and it can be huge. My key.asc file is 137,424 bytes following
your instructions.

Additionally, --export-secret-key actually includes everything from
--export, it just *adds* the secret key material to it. So there is no
need to do both --export and --export-secret-key; it just doubles the
information from --export.

What you're probably looking for is:

$ gpg2 --armour --output key.asc --export-options export-minimal
--export-secret-key [KEYID]
$ paperbackup.py key.asc
$ paperrestore.sh key.asc.pdf | diff key.asc -
$ lpr key.asc.pdf

However, I'm running into a little problem here myself... GnuPG 2.1.18
does not respect the "export-minimal" option for --export-secret-key,
only for --export. So if you are using GnuPG 2.1, this will not work as
intended.

This is in all likelihood a bug in GnuPG 2.1, and I'll report it right now.

Leaving aside this bug, export-minimal will achieve your goal: it will
only include the currently valid parts of the key without any
certifications by other keys. It is all you need to have a working key.
The certifications by other keys are on the keyservers.

Oh, as an aside, the advantage of paperkey is that it is
self-describing. No matter what happens, as long as we can still use
hexadecimal digits to describe binary content (which would be trivial to
reimplement), we can reconstruct the binary private key file. Using QR
codes has the disadvantage that if you cannot find a QR-code decoder for
your platform in the future, reimplementing one is far from trivial. You
are dependent on QR codes surviving as an actually supported data format.

Finally, I remember something about QR codes inherently supporting
splitting data over multiple individual code blocks, specifically for
data that is too large to fit in a single block. I don't know if it
supports the number of blocks you need, but you might want to check it
out. Also, you say large QR codes are easily damaged by wrinkles and
deformations. Is this perhaps related to the amount of error correction
data included? You can tune the ratio of content data to error
correction data, making a QR code more resilient to damage. However, if
you find that it is not unreadable individual pixels but rather the
deformation of the total that is throwing off decoders, than I suppose
the ratio doesn't help: it either can reduce it to the required square
or it cannot, I'd think.

HTH,

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>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20170222/c9472180/attachment.sig>