How do you safely backup a GPG private key?

Question

I found a very interesting CLI password manager called pass. To use it, you generate a GPG2 key pair, and use the tool to help you store passwords in gpg2 encrypted files.

To encrypt the files (add a new password), it uses the public key.

To decrypt the files (retrieve a stored password), it uses the private key, which requires a password.

This works great.

Now that the tool is storing all my passwords, I want to backup all this data so that if my computer crashes, I won't be locked out of all my online accounts.

The tool integrates nicely with git, so I was able to easily push the .gpg files to my private git repo on a different computer. From what I understand, these files are useless without the private key to decrypt them.

My question is this: how do I backup the private and public keys in a safe way, so that I can restore the "database" on another machine if the need arises? Can I just store both the public and private keys in my git repo, and import them on a different machine at a later time? Or is it considered unsafe practice to store a private key in a private, local git repo? The git repo requires a password to access. The private key is encrypted, and requires a password to open - does that make it safe to store?

Answer 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.

Answer 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.

Answer 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.

Answer 4

Another answer to this is "offline", i.e. storing it in some place that is secure and not connected to any computer. I keep a full, unencrypted copy of all my keys on a floppy disk (I've been doing it this way for a long time, now it's a habit) in the safety deposit box at the bank. The reason I keep them unencrypted on the media at the bank is that one potential scenario for "losing" the key is forgetting the pass phrase (my pass phrases tend to have lots of weird punctuation and spellings, and forgetting just one of those makes it unusable). I have never had to resort to getting it back from that copy, but I plan for the worst.

Additionally, there's a key revocation on the media and a note instructing my heirs on what to do with it, in the case I'm no longer available.

Answer 5

A good solution to safely backup a gpg private key is to print it on paper.

There is paperkey for this, see https://wiki.archlinux.org/index.php/Paperkey

One can also use off-the-shelf software for creating QR codes, see https://www.saminiir.com/paper-storage-and-recovery-of-gpg-keys/