What are the critical files I need to backup from GPG? I guess my private key would qualify of course, but what else?
6 Answers
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.
- 831
First of all, before we begin, in the commands below, your@id.here 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 your@id.here > your@id.here.pub.asc
gpg --export-secret-keys --armor your@id.here > your@id.here.priv.asc
gpg --export-secret-subkeys --armor your@id.here > your@id.here.sub_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 your@id.here.pub.asc
gpg --import your@id.here.priv.asc
gpg --import your@id.here.sub_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 your@id.here
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.
- 361
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.)
- 17,092
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).
- 211
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.
- 130