Paperkey - an OpenPGP key archiver
by David Shaw
A reasonable way to achieve a long term backup of OpenPGP (GnuPG, PGP,
etc) keys is to print them out on paper. Paper and ink have amazingly
long retention qualities - far longer than the magnetic or optical
means that are generally used to back up computer data.
Earlier releases as well as the usual GitHub stuff are available on GitHub.
- For POSIX (Linux, Unix, *BSD, etc):
(OpenPGP signature from my key 0x99242560)
- Win32 precompiled binary:
(OpenPGP signature from my key 0x99242560)
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, or similar), only archiving 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, OCR, QR code,
or the like) 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 key (plus some minor
packet structure) come to only 149 bytes. It's a lot easier to
re-enter 149 bytes correctly.
Different key algorithms will benefit to a different degree from this
size reduction. In general, DSA or Elgamal keys benefit the most,
shrinking to around 10% of the original key size, and RSA keys benefit
the least, only shrinking to about 50% of the original key size. ECC
keys are in between, shrinking to around 20-25% of the original, but
of course, ECC keys are quite small to begin with, and 25% of a small
number can compare well to 10% of a larger number.
As with any backup or archiving system, it is prudent to verify you
can restore the key from your paper copy before filing the paper away.
Aren't CD-Rs supposed to last a long time?
They're certainly advertised to (and 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.
In comparison, to claim that paper 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
methods of storing data.
Note that paperkey does not change the security requirements of
storing a secret key. In fact, paperkey doesn't do any crypto at all,
but just saves and restores the original secret key, whether it is
encrypted or not. 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
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 so you can
do things like:
gpg --export-secret-key my-key | paperkey | lpr
Some other useful options are:
Full documentation for all options is in the man page.
- 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 or QR code generator (although note that scannable codes have
some of the disadvantages discussed above).
- same as --output-type, but for the restore side of things. By
default the input type is inferred automatically from the input data.
- sets the width of base16 output (i.e. given your font, how many
columns fit on the paper you're printing on). Defaults to 78.
- 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
Paperkey ships with a RPM spec file. You can build the RPM with the
usual "rpmbuild -ta /path/to/the/paperkey/tarball.tar.gz".
Paperkey is Copyright © 2007-2018 by David Shaw