Back up the new PGP key

Once your PGP key and subkeys have been created, you NEED to make one or more backups of the key.

Backup the Tails stick

The easiest and most obvious way is to make a backup of your Tails stick. This way if something happens to your primary Tails stick, you can boot the backup just like you did with the primary, and make a new backup from there if needed.

⇒ Making a backup of your Persistent Storage.

Export to files

Another option, which you can do if you're not using Tails, is to export the public and secret keys, and a revocation certificate, and store them somewhere safe. This could mean another USB stick (preferably encrypted, but definitely not physically accessible to others). It could also mean a directory under /keybase/private/YOURNAME/.

Personally, I have a backup of my Tails stick stored in a fire safe at home, an encrypted USB stick in a safety deposit box at the credit union, and another encrypted USB stick in the fire safe of a family member in another part of the country.

Public Keys

If you exported your public key in order to send to other people, this is exactly the same operation. Feel free to copy that file into your backup location.

For the purposes of this section, I'm going to assume that you're using Tails, and are backing up the key files to the /home/amnesia/Persistent/gpg-backup/ directory.

$ mkdir -p ~/Persistent/gpg-backup/$KEYID
$ cd ~/Persistent/gpg-backup/$KEYID

Once you're in this directory, export the public key to a file.

$ gpg --export -a -o $KEYID.pub.asc $KEYID

ℹī¸ This file can be freely shared with the world, and in fact you will probably end up doing this at some point.

Secret Keys

When you export a secret key, the exported file will still be protected using the passphrase. This can be a problem if, two years from now when you need to restore from that backup, you've also forgotten what the passphrase was.

There are two solutions to this:

  • Store the passphrase in a text file with the exported secret key files.

    Be very careful if you do this, especially if you're using the same passphrase for other things (including other PGP keys). If somebody manages to get your backed-up files, not only would they have this PGP key, they would also have access to everything else you may be protecting with that passphrase.

    If you're going to do this, skip over the "Remove the passphrase" and "Add the passphrase again" sections below, and only use the "Export the secret keys" section.

  • Remove the passphrase before exporting the key, and then add the passphrase again afterward.

I normally remove the passphrase before exporting secret keys. I figure storing the passphrase with the secret key is just as insecure as not having a passphrase, and when/if the time comes that I need to restore the secret key, not having to deal with a passphrase will just make things a little bit easier at that time.

Remove the passphrase

Removing a passphrase is just changing the passphrase to an empty value.

$ gpg --edit-key $KEYID
...
gpg> passwd

Pay attention to what each "pinentry" prompt is asking you.

  • The FIRST password prompt will need the current passphrase.

  • For all of the remaining password prompts, don't enter a password.

  • When it asks (a few times) if you're really sure you want to do that, obviously say yes.

gpg> q

Export the secret keys

$ gpg --export-secret-key -a -o $KEYID.sec.asc $KEYID

If you've removed the passphrase, this will not ask for a passphrase, it will just create the output file.

🛑 These files should not be shared with ANYONE.

Obviously.

Add the passphrase again

$ gpg --edit-key $KEYID
...
gpg> passwd

This is just like before, but "in reverse". And where the current password is empty, it won't ask you to enter it - it'll just ask for the new password, once for the primary key and once for each subkey.

🛑 BE VERY CAREFUL to enter the same password for all of them.

It is possible to have different passwords for each key or subkey, but things get really confusing if you do that.

Revocation Certificate

Every backup should include a copy of a revocation certificate.

When you first created the primary key, there should have been a line like this in the output:

gpg: revocation certificate stored as '/home/amnesia/.gnupg/openpgp-revocs.d/0123456789ABCDEF0123456789ABCDEF01234567.rev'

If so, copy this file into the backup.

$ cp /home/amnesia/.gnupg/openpgp-revocs.d/$KEYID.rev .

Otherwise, we need to generate a new revocation certificate. This one is just going to sit there in the backup in case it's ever needed, so we're not going to enter a reason.

$ gpg --gen-revoke -o $KEYID.rev.asc $KEYID

sec  rsa4096/7EC2200541FD4588 2023-05-06 derp

Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
  0 = No reason specified
  1 = Key has been compromised
  2 = Key is superseded
  3 = Key is no longer used
  Q = Cancel
(Probably you want to select 1 here)
Your decision? 0
Enter an optional description; end it with an empty line:
>
Reason for revocation: No reason specified
(No description given)
Is this okay? (y/N) y
ASCII armored output forced.
Revocation certificate created.

Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable.  But have some caution:  The print system of
your machine might store the data and make it available to others!

Sharing a Revocation Certificate

This file should not be shared with the world at large. However, should think about giving a copy to somebody that you really trust, with instructions to share it with the world if something happens and you're no longer around.

Things to consider ...

  • The person you trust with the revocation certificate will be able to share it with the world. They will not be able to decrypt or sign messages.

  • If something happens and you're no longer around, you probably want the revocation certificate to be sent out, so that people who have your public key will know not to use it anymore.

  • If anybody imports the revocation certificate, and then shares your public key, the "revoked" status will also be shared.

  • Even better (or worse?), if somebody uploads your now-revoked public key to a keyserver, the "revoked" status will permanently be in that keyserver. And if that keyserver synchronizes with other keyservers, they will all consider the key to be revoked. And anybody who downloads or updates the public key from those keyservers, will also consider the key to be revoked.

You want your friend to have access to it so they can share it, but you also need to trust them not to share it unless you're not around anymore.

Copying the files

Once you have these files, you need to send them "out of Tails". There are a few ways to do this.

Keybase

It's not the easiest thing in the world, but it is possible to run Keybase within Tails. At some point I plan to make a "book" like this one, but for now I have a one-page document with notes about how to do it.

⇒ /keybase/public/jms1/notes/Tails/Keybase on Tails.md

If you are running Keybase on Tails, create a directory under /keybase/private/YOURNAME/ and copy the files there.

Encrypted USB stick

If the only computers which will need to access the encrypted USB stick are running Linux (including Tails), you can encrypt it using LUKS.

⇒ Tails - Creating and using LUKS encrypted volumes

If other operating systems will need to access the encrypted USB stick, you'll need to use VeraCrypt instead. VeraCrypt is available for Linux, macOS, and windows. It's a fork of an earlier system called TrueCrypt, which is no longer maintained.

Tails comes with software which can open existing VeraCrypt volumes, but it cannot create them. You will need to create an encrypted volume using VeraCrypt on another system, and then mount that volume under Tails.

⇒ Tails - Using VeraCrypt encrypted volumes

Whether you're using LUKS or VeraCrypt, the overall process is the same ...

  • Mount the encrypted USB stick. (This is covered by the Tails documentation linked above.)

  • Copy the files into the encrypted USB stick.

    I recommend creating a directory within the encrypted USB stick, to keep these files together and to keep them separate from other things you may wish to store.

  • Un-mount the encrypted USB stick. (This is covered by the Tails documentation linked above.)

SSH

This obviously depends on having a machine that you can SSH into.

Creating an encrypted tarball

To do this, we're going to create a PGP-encrypted message containing a ZIP file.

Before we can do this ... Tails doesn't come with the zip command installed, so we'll need to install it first.

$ sudo apt update
...
$ sudo apt install zip

If you turned on the "Additional Software" item when configuring Persistent Storage, you will get a pop-up message asking whether you want to "Install Only Once", or "Install Every Time" you boot Tails. Either way, it's up to you.

Once the command is installed, you can create the PGP-encrypted ZIP file like so ...

$ cd ~/Persistent/gpg-backup/$KEYID/
$ zip -9 - $KEYID.* | gpg -ear RECIPIENT -o newkey.zip.asc

  • RECIPIENT is the identity of whoever needs to be able to decrypt the file. This can be a Key ID, or it can be a name or email, if the keyring only has a single key matching.

    You can use gpg -k RECIPIENT before creating the tarball if you need to verify that the keyring only has one matching key.

This will create a file called newkey.zip.asc, containing the message. If you look at the file, you will see that it starts with "-----BEGIN PGP MESSAGE-----", and contains a big block of random-looking characters.

This file can safely be sent via SSH, email, chat, or any other method. It can only be decrypted by RECIPIENT.

Sending the file

Copy the file using the scp command, like you would any other file.

$ scp newkey.txt hostname.server.xyz:

Email

See above for directions on how to create a PGP-encrypted message containing a tarball of the key files.

Assuming you followed those directions, and you have Thunderbird set up to send and receive email, you can email the newkey.zip.asc file to yourself.