How do you safely backup a GPG private key?

Solution 1:

Storing a PGP private key in a revision control system does not, in and of itself, pose any significant security issues. Storing the private key in a local, private (unpublished) git repository should have no significant security implications versus storing the private key on the same computer but outside of any git repository.

The only issue I can think of that comes from storing the private key in a version-controlled manner is that unless you can somehow destroy the older revisions, key passphrase changes buy you far less protection than they otherwise might.

What can come with its own set of security implications is storing a private key in such a way that someone else might be able to get access to the key file. In such a situation, all that stands between an attacker and your key is the strength of its passphrase.

Recognizing that storage security isn't perfect, and even more so in the modern environment where people regularly back up to cloud services (which literally translated means "someone else's computer"), we usually protect our secret keys with passphrases. I trust that, even if you are running for example gpg-agent, you are doing the same.

The bottom line is that, as long as your passphrase is good, even storing a copy of the encrypted key file on someone else's computer should be relatively safe.

However, that's a pretty big if: most peoples' passwords or passphrases are rather lousy as far as computerized attempts at cracking them go. GnuPG goes to quite some length to try to work as well as it can with what you give it, but for solid data protection, you need a good passphrase, and you need to set it before importing the private key into the git repository. After the key has been imported, an attacker could in principle attack any version of it, and if they have reason to believe that a particular revision has a lower-quality passphrase will likely go for that. For that reason, make sure that you pick the passphrase with care. I have written up a small primer on how to handle passwords, including suggestions on how to choose passwords or passphrases that you need to be able to remember, which you may find useful.

Solution 2:

I've been considering a similar setup recently. Before tackling your question, let me point out what bothers me about it. This is explained at great length here. In short- when Pass calls GPG, it performs unnecessary asymmetric (RSA/EC) crypto under the hood. Unnecessary- because there is no untrusted party here.

This is annoying because asymmetric crypto is less future-proof than symmetric crypto. E.g., asymmetric crypto of today is broken by sufficiently large quantum computers, that do not exist, yet. More generally, asymmetric crypto relies of "math problems" we do not know how to solve, much more so than symmetric crypto.

To mitigate this weakness, the least you could do is to keep your GPG public key used with Pass private as well, because for instance the (potential) quantum attack needs this public key: see here.

On to your actual question, it is unclear whether you intend to store the git repo (with the passwords) publicly or privately. If you want to keep it private, you can pretty much do what you want, and reduce the security of the GPG private key to that of the medium where you back up the repo. However, that might become a chicken and egg problem: if the repo is private, how do you get it back in case of a crash? In other words, in case of a "bad crash", there must be something you retrieve first. So you might want to keep the git repo private, but backup the GPG key in such a way that you can retrieve first, independently of anything else.

Offline back up solutions are numerous, lawyers, basements, etc. see here. But basements aren't for everyone, so let me suggest an online solution:

• Create a super strong passphrase that is not meant to be typed for years. Suggestion: Long, memorable misspelling of a phrase that has some personal significance, or from a book that won't run out of copies if you need to look it up.

• Create a tarball with your exported GPG secret key, and maybe your SSH credentials.

• Encrypt it symmetrically with your passphrase: gpg --symmetric --armor.

• Create a free git hosting account.

• Create a public repository, that can be cloned without credentials.

• Put the encrypted&armored tar ball in there.

To retrieve it after a "bad crash":

• Boot a live USB stick.

• Clone public repo.

• gpg --decrypt.

The symmetric passphrase will be your main protection against the zombies. People sometimes do not give you, or the anonymous reader, the benefit of the doubt when it comes to choosing passphrases. But with a good passphrase, symmetric crypto should be solid.

When you export your GPG private key, it will be encrypted with a passphrase of its own. Recent versions of GPG won't allow an unencrypted export. You might use your "regular" GPG passphrase here. Just remember that in the event of a crash, you will need both passphrases to get to your GPG private key.

Solution 3:

Another option I use is: Print your key on paper.

The details are in the linked answer. The big advantages are: You can easily store it wherever you want and you can check if it is still likely in good shape by just looking at it. But the biggest advantage is: No one can hack it without actually physically being in the place where you store your backup and taking it.