If you’re a software developer working ethically you’re almost certainly using GnuPG to sign your work. And if you’ve been at it for any length of time you’ve almost certainly been forced to switch machines. Unless your aim is to create a new identity for each machine you use you need a simple, repeatable strategy moving GPG keys privately. Let me show you how.
First let’s look at a flat-out bad approach:
gpg --export-secret-keys --armor SOMEKEYID > secret.asc
The above comes from one of the most popular answers related to moving GPG keys on StackOverflow and it’s not at a all good method. Here’s why:
- Passwordless keys will be saved in cleartext unbeknownst to some users.
- Output file screams brute-force me:
-----BEGIN PGP PRIVATE KEY BLOCK-----. - The key has just one password to crack for anyone with the resources.
Given the answer was admittedly cobbled together from comments below it we see here a clear case of design by committee and its impact on security applications. Use the above if you’re planning to create a paper backup, as noted in man gpg.
Now let’s look at the Dark Otter approach:
gpg --output pubkey.gpg --export SOMEKEYID && \
gpg --output - --export-secret-key SOMEKEYID |\
cat pubkey.gpg - |\
gpg --armor --output keys.asc --symmetric --cipher-algo AES256
And then import from the resulting keys.asc file:
gpg --output - keys.asc | gpg --import
This approach has its merits:
- Intermediate file does not suggest its a PRIVATE KEY at all.
- Password protects passwordless keys using --symmetric encryption.
- Specifies encryption algo, in case you’re reading this in 2040.
- Public key made available alongside the private key.
And it has its drawbacks:
- Creates two intermediate files, the first of which is unnecessary.
- Resulting keys.asc can still be brute-forced if an attacker gets a copy.
- It’s clever. So clever, in fact, good luck remembering what’s inside.
Use this Dark Otter approach if you need to back-up your keys to a physical medium and a paper backup or second layer of encryption such as a file system or SSH transport isn’t practical. Just make sure you create a treasure map so you know how to get back to what you buried.
Note: Rick Duggan followed up to note he saw gpg trow some errors later while attempting to encrypt data using the private keys imported using this approach. He said he saw were errors gpg: [recacted]: There is no assurance this key belongs to the named user and gpg: [stdin]: encryption failed Unusable public key and noted they were caused before he adjusted the trust level of his keys following the import from keys.asc. Thanks again, Rick!
Finally, let’s see about moving GPG keys privately with minimal fuss. This approach I learned from Neil Mayhew. It requires the machines to be networked with ssh access to the destination machine.
Tip: For added security do this in an air gapped environment using a spare router or networking the devices directly, something you may have already done in order to use Midnight Commander to transfer files between them.
If you’re on the machine that already has the key:
gpg --export-secret-key SOMEKEYID | ssh othermachine gpg --import
If you’re on the machine that needs the key:
ssh othermachine gpg --export-secret-key SOMEKEYID | gpg --import
As Neil notes no intermediate files are created using this method and it has the advantage of allowing granular control over which keys are moved between machines. Use this approach if you have SSH access to the destination machine and are not already restoring your GPG keys from a backup due to a lost or borked machine.
And there you have it. A simple, elegant way to privately move your GPG keys from one machine to another. And knowledge of the pros and cons of some other methods. Now go forward and continue developing your illustrious empire of ethical code. Just remember not to forget to securely backup your work from time to time.