A reasonable way to achieve a long term backup of OpenPGP (GnuPG, PGP, etc) keys is to print them out on paper.. #OpenPGP backup #GnuPG metadata #Key archiver #OpenPGP #GnuPG #PGP
Paperkey is a reasonable way to achieve a long term backup of OpenPGP (GnuPG, PGP, etc) keys is to print them out on paper. 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 backed up in this way (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.
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.
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.
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.
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 --output my-key-text-file.txt
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 (though note that bar codes have many of the disadvantages discussed above).
--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.
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.
What's new in Paperkey 1.3:
- This versiob adds support for OpenPGP elliptic curve keys (ECDH and ECDSA) as specified in RFC 6637.
- It uses minimal OpenPGP packet encoding.
- This does not affect functionality, but makes it more likely that a given key will match byte-for-byte the same key after running through paperkey.
Paperkey 1.3
add to watchlist add to download basket send us an update REPORT- runs on:
- Linux
- filename:
- paperkey-1.3.tar.gz
- main category:
- Security
- developer:
- visit homepage
7-Zip 23.01 / 24.04 Beta
Context Menu Manager 3.3.3.1
IrfanView 4.67
Windows Sandbox Launcher 1.0.0
Bitdefender Antivirus Free 27.0.35.146
calibre 7.9.0
Microsoft Teams 24060.3102.2733.5911 Home / 1.7.00.7956 Work
ShareX 16.0.1
4k Video Downloader 1.5.3.0080 Plus / 4.30.0.5655
Zoom Client 6.0.3.37634
- ShareX
- 4k Video Downloader
- Zoom Client
- 7-Zip
- Context Menu Manager
- IrfanView
- Windows Sandbox Launcher
- Bitdefender Antivirus Free
- calibre
- Microsoft Teams