Printing Keys and using OCR (was: Proofreadable base64)

[David Shaw]

On Fri, Sep 21, 2007 at 12:59:00AM +0200, Peter Palfrader wrote:
> On Mon, 28 May 2007, Peter S. May wrote:
> 
> > Not meaning to kick a dead thread
> 
> This must be a zombie by now :)

Indeed.  I'm very glad the thread woke up again, though, as it
reminded me that I had written some code for this back in May, but
unfortunately let it get buried under other work.  I've tidied things
a bit and packaged it at http://www.jabberwocky.com/software/paperkey/

It implements a secrets-only backup via paper (or bar code, or
whatever you like), and then allows you to rebuild the original secret
key when you like.

README file is attached.

David
-------------- next part --------------
		  Paperkey - an OpenPGP key archiver
		  ----------------------------------
		  David Shaw <dshaw at jabberwocky.com>


A reasonable way to achieve a long term backup of OpenPGP (GnuPG, PGP,
etc) keys is to print them out on paper.  The reasoning behind this is
that paper and ink has amazingly long retention qualities - far longer
than the magnetic or optical means that are generally used to back up
computer data.

Paper?  Seriously?
------------------

The goal with paper is not secure storage.  There are countless ways
to store something securely.  A paper backup also isn't a replacement
for the usual machine readable (tape, CD-R, DVD-R, etc) backups, but
rather as an if-all-else-fails method of restoring a key.  Most of the
storage media in use today do not have particularly good long-term
(measured in years to decades) retention of data.  If and when the
CD-R and/or tape cassette and/or USB key and/or hard drive the secret
key is stored on becomes unusable, the paper copy can be used to
restore the secret key.

What paperkey does
------------------

Due to metadata and redundancy, OpenPGP secret keys are significantly
larger than just the "secret bits".  In fact, the secret key contains
a complete copy of the public key.  Since the public key generally
doesn't need to be escrowed (most people have many copies of it on
various keyservers, web pages, etc), only extracting the secret parts
can be a real advantage.

Paperkey extracts just those secret bytes and prints them.  To
reconstruct, you re-enter those bytes (whether by hand or via OCR) and
paperkey can use them to transform your existing public key into a
secret key.

For example, the regular DSA+Elgamal secret key I just tested comes
out to 1281 bytes.  The secret parts of that (plus some minor packet
structure) come to only 149 bytes.  It's a lot easier to re-enter 149
bytes correctly.

Aren't CD-Rs supposed to last a long time?
------------------------------------------

They're certainly advertised to (I've seen some pretty incredible
claims of 100 years or more), but in practice it doesn't really work
out that way.  The manufacturing of the media, the burn quality, the
burner quality, the storage, etc, all have a significant impact on how
long an optical disc will last.  Some tests show that you're lucky to
get 10 years.

For paper, on the other hand, to claim it will last for 100 years is
not even vaguely impressive.  High-quality paper with good ink
regularly lasts many hundreds of years even under less than optimal
conditions.

Another bonus is that ink on paper is readable by humans.  Not all
backup methods will be readable 50 years later, so even if you have
the backup, you can't easily buy a drive to read it.  I doubt this
will happen anytime soon with CD-R as there are just so many of them
out there, but the storage industry is littered with old now-dead ways
of storing data.

Examples
--------

Take the secret key in key.gpg and generate a text file
to-be-printed.txt that contains the secret data:

$ paperkey --secret-key my-secret-key.gpg --output to-be-printed.txt

Take the secret key data in my-key-text-file.txt and combine it with
my-public-key.gpg to reconstruct my-secret-key.gpg:

$ paperkey --pubring my-public-key.gpg --secrets my-key-text-file.txt --output my-secret-key.gpg

If --output is not specified, the output goes to stdout.  If
--secret-key is not specified, the data is read from stdin.

Some other useful options are:

  --output-type      can be "base16" or "raw".  "base16" is human-readable,
		     and "raw" is useful if you want to pass the output to
		     another program like a bar code generator.

  --input-type       same as --output-type, but for the restore side of
		     things.  By default the input type is inferred
		     automatically from the input data.

  --output-width     sets the width of base16 output

  --ignore-crc-error allows paperkey to continue when reconstructing
		     even if it detects data corruption in the input.

  --verbose (or -v)  be chatty about what is happening.  Repeat this
		     multiple times for more verbosity.

Security
--------

Note that paperkey does not change the security requirements of
storing a secret key.  If your key has a passphrase on it (i.e. is
encrypted), the paper copy is similarly encrypted.  If your key has no
passphrase, neither does the paper copy.  Whatever the passphrase (or
lack thereof) was on the original secret key will be the same on the
reconstructed key.

Universal Binaries on Apple OS X
--------------------------------

You can build a universal ("fat") library that will work on both PPC
and Intel Macs with:

./configure CFLAGS="-arch ppc -arch i386" --disable-dependency-tracking

Note that if you are doing the build on a OS X 10.4 (Tiger) PPC
machine you may need to add the following to those CFLAGS:

  "-isysroot /Developer/SDKs/MacOSX10.4u.sdk"

The additional isysroot is not necessary on Intel Tiger boxes, or any
Leopard boxes.

RPM
---

Paperkey ships with a RPM spec file.  You can build the RPM with the
usual "rpmbuild -ta /path/to/the/paperkey/tarball.tar.gz".

$Id: README 314 2007-09-21 22:52:05Z dshaw $