paperkey
This commit is contained in:
parent
cbeee49bc8
commit
20a1e06a46
GPG Key ID:
E47FE0AB36CD5ED6
140
content/posts/2023/privacy/paperkey.md
Normal file
140
content/posts/2023/privacy/paperkey.md
Normal file
@ -0,0 +1,140 @@
|
|||||||
|
---
|
||||||
|
title: "🔐 Paperkey - an OpenPGP key archiver"
|
||||||
|
date: 2023-04-05T12:49:30+03:00
|
||||||
|
draft: false
|
||||||
|
tags: [gpg, privacy, backup]
|
||||||
|
---
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
|
||||||
|
## Download
|
||||||
|
|
||||||
|
**For POSIX (Linux, Unix, \*BSD, etc):**
|
||||||
|
|
||||||
|
* [paperkey-1.6.tar.gz](https://github.com/dmshaw/paperkey/releases/download/v1.6/paperkey-1.6.tar.gz)
|
||||||
|
* [paperkey-1.6.tar.gz.sig](https://github.com/dmshaw/paperkey/releases/download/v1.6/paperkey-1.6.tar.gz.sig) (OpenPGP signature from my key 0x99242560)
|
||||||
|
|
||||||
|
**Win32 precompiled binary:**
|
||||||
|
|
||||||
|
* [paperkey-1.6-win32.zip](https://github.com/dmshaw/paperkey/releases/download/v1.6/paperkey-1.6-win32.zip)
|
||||||
|
* [paperkey-1.6-win32.zip.sig](https://github.com/dmshaw/paperkey/releases/download/v1.6/paperkey-1.6-win32.zip.sig) (OpenPGP signature from my key 0x99242560)
|
||||||
|
|
||||||
|
[Earlier releases as well as the usual GitHub stuff are available on GitHub](https://github.com/dmshaw/paperkey/).
|
||||||
|
|
||||||
|
## 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.
|
||||||
|
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.
|
||||||
|
|
||||||
|
## 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 **key.gpg** and generate a text file **to-be-printed.txt**
|
||||||
|
that contains the secret data:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
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**:
|
||||||
|
```sh
|
||||||
|
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:
|
||||||
|
|
||||||
|
```sh
|
||||||
|
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 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
|
||||||
|
(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 the RPM with the usual
|
||||||
|
`rpmbuild -ta /path/to/the/paperkey/tarball.tar.gz`.
|
||||||
Loading…
Reference in New Issue
Block a user