54

What are the critical files I need to backup from GPG? I guess my private key would qualify of course, but what else?

0

6 Answers 6

55

The most critical are your secret/private keys:

gpg --export-secret-keys > secret-backup.gpg

secret-backup.gpg is then the file to keep safe.

Otherwise the ~/.gnupg/ directory contain all private and public keys(secring.gpg and pubring.gpg respectively) as well as configuration and trustdb which could be convenient to have stored.

4
  • 3
    If a public key was lost, would the private key be useless?
    – Buttons840
    May 4, 2019 at 15:49
  • 2
    @Buttons840 The public key is a subset of the private key so you should be able to extract the public key from the private.
    – hultqvist
    May 4, 2019 at 18:21
  • 2
    Recent versions of GnuPG do not have pubring.gpg, but pubring.kbx and private keys are in a separate directory.
    – jarno
    May 3, 2020 at 6:11
  • 2
    Use gpg --import ~/secret-backup.gpg to restore the exported private keys.
    – 030
    Jul 30, 2021 at 14:27
23

First of all, before we begin, in the commands below, [email protected] should be replaced with the specific identifier of your GPG key. You can use your email address associated with the key, the long form of the key ID, or the short form.

Indeed, your private key is critical, but other files are also important.

1. Export keys and ownertrust:

These commands are intended to export your keys and trust level. Public and private keys are used for encryption/decryption, and the trust level determines how much you trust other keys in your keyring.

Run the following commands in your command line (Command Prompt for Windows, Terminal for macOS and Linux):

gpg --export --armor [email protected] > [email protected]
gpg --export-secret-keys --armor [email protected] > [email protected]
gpg --export-secret-subkeys --armor [email protected] > [email protected]_priv.asc
gpg --export-ownertrust > ownertrust.txt

2. Import keys and ownertrust:

If you need to restore your keys and trust level (e.g., after reinstalling the system or on a new computer), use the following commands:

gpg --import [email protected]
gpg --import [email protected]
gpg --import [email protected]_priv.asc
gpg --import-ownertrust ownertrust.txt

3. Ultimately trust the imported key:

This step is needed to set the ultimate trust level for your keys. Run the following command, then type trust, then 5 (which means "ultimate trust") and hit Enter:

gpg --edit-key [email protected]
gpg> trust
Your decision? 5

Note: If you're operating on Windows, you might need to install GPG4Win first. If you're on macOS, you may need to install GPG Suite.

Update 2023.07.21

An essential point I'd like to address is related to suggestions about backing up the entire ~/.gnupg/ directory. This practice might seem straightforward and quick, but it comes with its pitfalls.

Yes, the ~/.gnupg/ directory does contain all your private and public keys, as well as the trust database and other useful data. However, it also includes your key revocation certificates (~/.gnupg/openpgp-revocs.d/), which are not advisable to include in your backup. This is because if your backup gets stolen or lost, a malicious actor could revoke your keys, rendering them unusable.

Moreover, the ~/.gnupg/ directory may contain temporary files and other less critical data that you might not need during restoration, and it might unnecessarily increase the size of your backup.

Exported files are more portable and easier to import onto other systems or after a reinstall, compared to copying the entire ~/.gnupg/ directory, which might cause compatibility issues between different versions of GPG or operating systems.

On the other hand, exporting keys and trust level, as I explained above, allows for more controlled and secure data management. This approach minimizes risks and makes the process more reliable and predictable.

So, while copying the entire ~/.gnupg/ directory might seem like a quick solution, it may not be the best option in terms of data security and management.

Update 2024.04.07

A fair point has been raised in the comments:

"if your backup gets stolen or lost, a malicious actor could revoke your keys" - if our backup gets stolen, we should revoke our keys anyway, so why does it matter?

Indeed, if your backup is stolen, revoking your keys is the safest course of action. However, there are a few reasons why I still recommend exporting keys and trust levels instead of backing up the entire ~/.gnupg/ directory.

Depending on the circumstances, you might not immediately realize that your backup has been stolen or lost. Exporting keys separately gives you a window to respond and revoke the keys on your own terms before they can be misused. This allows you to control when and how to revoke them, giving you time to notify contacts and take other necessary steps in a controlled manner.

If revocation certificates are readily available in the stolen backup, a malicious actor could instantly revoke your keys, causing more disruption and potentially catching you off guard. By not including revocation certificates in your backup, you minimize the potential damage if the backup is compromised.

Ultimately, the choice of backup method depends on your specific situation and security requirements. If you're confident in your ability to secure a full ~/.gnupg/ backup and value the ability to quickly revoke keys, including revocation certificates might be justified. However, from the perspective of data security and management, backing up the entire ~/.gnupg/ directory with all its contents is not considered the best practice. It might be acceptable in certain cases, but it's not advisable to recommend it as a general approach for everyone.

2
  • 1
    "if your backup gets stolen or lost, a malicious actor could revoke your keys" - if our backup gets stolen, we should revoke our keys anyway, so I don't get this point
    – Taylan
    Apr 7 at 9:44
  • 1
    @Taylan You're right, if our backup is stolen, we should revoke our keys. However, if the revocation certificates are not included in the backup, we have a window to revoke the keys on our own terms before the malicious actor can. This allows us to notify contacts and take necessary steps in a controlled manner, minimizing disruption. The timing and control over the revocation process can make a difference in mitigating the impact of the theft.
    – serghei
    Apr 7 at 16:16
15

The easiest way would be to grab the entire GnuPG directory - usually ~/.gnupg/, it contains all private keys you have, as well as the public keyring and other useful data (trustdb, etc.)

4
  • 1
    Isn't it also the safest way? Because the private keys are still encrypted.
    – tuxayo
    May 25, 2020 at 19:06
  • I have some weird files in my directory that does not want to be copied over scp
    – vidstige
    May 6, 2021 at 9:33
  • Don't copy them. They're sockets, not files. May 6, 2021 at 9:35
  • (Just dropping this here: why does gpg-agent create several sockets?)
    – toraritte
    Jan 26, 2023 at 3:43
11

In addition to @serghei's answer, check the documentation of gnupg. It says that you should backup:

  • ~/.gnupg/gpg.conf (standard configuration file)
  • ~/.gnupg/pubring.gpg (legacy public keyring)
  • ~/.gnupg/pubring.kbx (new public keyring using keybox format)
  • ~/.gnupg/openpgp-revocs.d/ (revocation certificates)

It suggests also to backup the ownertrust

gpg --export-ownertrust > otrust.txt

Of course, you should backup your secret keys as well. If I understand correctly, the quickest way would be using tar to backup the whole ~/.gnupg except revocation certificates ~/.gnupg/openpgp-revocs.d/. You may consider to print revocation certificates as a QR code (qrencode) or instead, print out secret keys with the utility paperkey (see reference). Remember that if you keep your private keys and revocation certificates in one device, an attacker can revoke your public key and issue a new one claiming to be you.

Reference: An Advanced Introduction to GnuPG, Neal H. Walfiel section 6.3.8 (creating a backup).

3
  • Why do we have to backup the public keyring? Aren't the public keys part of the secret keys? So exporting the secret keys + owner trust should be enough
    – trallnag
    Oct 13, 2021 at 19:22
  • 1
    @JellyFilledNuts It may contain other people's public key, thus not part of the secret ones you own. See the documentation. In that perspective, it's not dramatic to lose them, just not very handy. Oct 13, 2021 at 20:02
  • 1
    I see, that makes sense. Thanks. I did not think about that aspect because so far I'm using GPG only for signing commits and encrypting stuff
    – trallnag
    Oct 13, 2021 at 21:33
2

You definitely want to backup your private key and the revocation file you created.

2
  • where is the "revocation certificate" ?
    – jldupont
    Nov 18, 2009 at 22:07
  • You need to create it (if you didn't already). It is used to revoke your key if you loose your private key.
    – PEra
    Nov 24, 2009 at 18:17
0

You may also want to back up any keys you've signed or ones you don't feel like re-downloading off the key servers.

At a minimum, all you need is your complete key.

1
  • ...and any revocation certificates you created.
    – Broam
    Nov 18, 2009 at 22:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .