mirror of https://github.com/dmshaw/paperkey.git synced 2024-02-25 09:51:32 +00:00

Go to file

David Shaw 6ddd767b05 Merge pull request #5 from jonathancross/readme README: Convert to markdown and add build info.		2021-01-31 18:03:33 -05:00
checks	Clarify the selftests a bit	2020-03-20 09:34:42 -04:00
gl/m4	gnulib refresh (it needs autoconf 2.64 now)	2021-01-26 15:59:16 -05:00
.gitignore	Add .gitignore	2020-03-20 09:35:52 -04:00
AUTHORS	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
ChangeLog	Fix reporter	2017-11-17 12:27:50 -05:00
configure.ac	gnulib refresh (it needs autoconf 2.64 now)	2021-01-26 15:59:16 -05:00
COPYING	Use gplv2	2009-10-14 19:24:11 +00:00
extract.c	Properly fail if we cannot parse a secret subkey packet.	2017-10-23 16:18:12 -04:00
extract.h	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
Makefile.am	Make sure we clean up paperkey.txt so it can be regenerated	2013-01-03 23:14:24 -05:00
NEWS	Post-release commit	2018-10-19 10:12:11 -04:00
output.c	Fix binary vs text output mismatch when using "--output-type raw" on Windows platforms. Does not affect any non-Windows platforms. Found by Thierry Ambrus.	2016-09-05 18:20:36 -04:00
output.h	Fix binary vs text output mismatch when using "--output-type raw" on Windows platforms. Does not affect any non-Windows platforms. Found by Thierry Ambrus.	2016-09-05 18:20:36 -04:00
packets.c	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
packets.h	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
paperkey.1	Tweak to mention QR codes explicitly	2013-06-14 16:57:04 -04:00
paperkey.c	Fix binary vs text output mismatch when using "--output-type raw" on Windows platforms. Does not affect any non-Windows platforms. Found by Thierry Ambrus.	2016-09-05 18:20:36 -04:00
paperkey.spec.in	Use %license for the COPYING file and run the self checks during build.	2016-09-05 20:47:54 -04:00
parse.c	Add support for EdDSA as per https://tools.ietf.org/html/draft-koch-eddsa-for-openpgp-04 . Note that this is an expired draft, but GnuPG is using algorithm 22 for it.	2017-10-23 11:36:01 -04:00
parse.h	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
README.md	README: Convert to markdown and add build info.	2021-01-28 17:53:11 +01:00
README.WIN32	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00
restore.c	Cleanup: combine ptag with length into output_openpgp_header	2012-06-14 15:29:16 -04:00
restore.h	Remove various Id tags that hg doesn't use	2012-06-13 14:52:43 -04:00

README.md

Paperkey - an OpenPGP key archiver

David Shaw dshaw@jabberwocky.com

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.

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, or similar), only archiving the secret parts can be a real advantage.

Paperkey extracts just those secret bytes and prints them in a easily handled format. To reconstruct, you re-enter those bytes (whether by hand or via OCR) and paperkey uses 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.

Security

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 reconstructed key.

Examples

Take the secret key in my-secret-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:

--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 or
                   QR code generator (although note that scannable
                   codes have some of the longevity disadvantages
                   discussed above).  Defaults to "base16".

--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 (i.e. given your font,
          		     how many columns fit on the paper you're printing on).
                   Defaults to 78.

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

Full documentation for all options is in the man page.

RPM

Paperkey ships with a RPM spec file. You can build an RPM with the usual

rpmbuild -ta /path/to/the/paperkey/tarball.tar.gz

Building

Paperkey uses gnulib to provide SHA-1 and getopt_long functionality as they're not available on all platforms. If you want to build directly from the github version, try this:

git clone git://git.savannah.gnu.org/gnulib.git  # there is also a github mirror at https://github.com/coreutils/gnulib.git
git clone https://github.com/dmshaw/paperkey.git
cd paperkey
../gnulib/gnulib-tool --update
autoreconf -f -i
./configure
make check

Alternately, you can use the releases in github. Those include the gnulib code as part of the package.

Copyright