Create a gist now

Instantly share code, notes, and snippets.

What would you like to do?
Instructions for exporting/importing (backup/restore) GPG keys

Every so often I have to restore my gpg keys and I'm never sure how best to do it. So, I've spent some time playing around with the various ways to export/import (backup/restore) keys.

Method 1

Backup the public and secret keyrings and trust database

cp ~/.gnupg/pubring.gpg /path/to/backups/
cp ~/.gnupg/secring.gpg /path/to/backups/
cp ~/.gnupg/trustdb.gpg /path/to/backups/
# or, instead of backing up trustdb...
gpg --export-ownertrust > chrisroos-ownertrust-gpg.txt

NOTE The GPG manual suggests exporting the ownertrust instead of backing up the trustdb, although it doesn't explain why.

Restore the public and secret keyrings and trust database

cp /path/to/backups/*.gpg ~/.gnupg/
# or, if you exported the ownertrust
gpg --import-ownertrust chrisroos-ownertrust-gpg.txt

Method 2

This only really works if you don't mind losing any other keys (than your own).

Export public and secret key and ownertrust

gpg -a --export chris@seagul.co.uk > chrisroos-public-gpg.key
gpg -a --export-secret-keys chris@seagul.co.uk > chrisroos-secret-gpg.key
gpg --export-ownertrust > chrisroos-ownertrust-gpg.txt

Import secret key (which contains the public key) and ownertrust

gpg --import chrisroos-secret-gpg.key
gpg --import-ownertrust chrisroos-ownertrust-gpg.txt

Method 3

This is mainly about trusting my key once I've imported it (by either restoring the pubring.gpg and secring.gpg, or by using --import). This seems to be what I do the most as I either forget to import the trustdb or ownertrust.

Ultimately trust the imported key

This is so that I can encrypt data using my public key

gpg --edit-key chris@seagul.co.uk
gpg> trust
Your decision? 5 (Ultimate trust)

NOTE If I don't trust the public key then I see the following message when trying to encrypt something with it:

gpg: <key-id>: There is no assurance this key belongs to the named user

Regarding the trustdb vs ownertrust export thing: the GPG manual actually does explain why --export-ownertrust is preferred, albeit on a different page:

This is useful for backup purposes as these values are the only ones which can't be re-created from a corrupted trustdb.

jeifour commented Jul 31, 2015

I still don't understand why this would be better over backing up the trustdb. The trustdb should only be corrupted if the backup is corrupted, I would assume. And if the backup is corrupted, the ownertrust.txt export would also be corrupted.

The trustdb should only be corrupted if the backup is corrupted, I would assume.

Not necessarily. The ownertrust export stores the values in plain text form (fingerprint:level), while trustdb don't. It could be corrupted because of GPG version incompatibilities and a number of other reasons.

r5d commented May 31, 2016

Wrote a script to automate the backup. It is at https://git.ricketyspace.net/dotfiles/plain/.bin/gnupg-backup

tzeejay commented Sep 13, 2016

Thanks for collecting this, and to everyone else for the thoughtful conversation.

xuhdev commented Feb 11, 2017

Is method 2 a superset of method 1? Seems method 1 is only one step in method 2.

Any ideas why importing ownertrust from file gives me gpg: error in 'myownertrustfile.txt' line too long ?

Very good! Thanks!

cmcginty commented Sep 15, 2017

You can simplify Method 3 a little by extending the command to:

gpg --edit-key chris@seagul.co.uk trust quit

There is also a way to run the command in a non-interactive mode:

expect -c "spawn gpg --edit-key chris@seagul.co.uk trust quit; send \"5\ry\r\"; expect eof"

@cmcginty nice usage of expect to automate this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment