GNU Privacy Guard Guide


Offline Your Secret Keys

Is it necessary?

Not really, but it does mean that in the event your computer / hard drive is compromised (lost, stolen, whatever), you'll be able to revoke you old signing and encryption keys and move to new ones without completely losing all the signatures to your public key.
It certainly won't help with rubber-hose or wrench-based cryptanalysis

Step 1: Back up the original keyring

Let's assume you have the following private keyring:

	PS D:\> gpg --list-secret-keys enigelstewart@gmail.com
	sec   rsa4096/0xADDE6EAA819563E9 2016-04-11 [SC] [expires: 2018-04-11]
		  Key fingerprint = 2968 D18E 6F78 1B68 FBBF  0EC1 ADDE 6EAA 8195 63E9
	uid                   [ultimate] Eric Stewart 
	ssb   rsa4096/0x2821B792843D7A59 2016-04-11 [E] [expires: 2018-04-11]
	ssb   rsa4096/0x695455DC87F1857F 2016-04-11 [S] [expires: 2018-04-11]
				
Export the private master key and its private subkeys:
	PS D:\> gpg --armor --output enigelstewart-private-keys.asc --export-secret-key enigelstewart@gmail.com		
				
Store the exported private keys in a secure place (not on your computer)

Step 2: Remove the private master key from the keyring

The “classic” method for doing that is to export your private subkeys, then delete all your private keys (the master private key and the private subkeys), and import back the private subkeys (because GnuPG prior to version 2.1 had no option to delete the master key only).
With GnuPG 2.1 however, there is a more direct method. First, find the keygrip of your master key:

	PS D:\> gpg --list-secret-keys --with-keygrip enigelstewart@gmail.com
	sec   rsa4096/0xADDE6EAA819563E9 2016-04-11 [SC] [expires: 2018-04-11]
		  Key fingerprint = 2968 D18E 6F78 1B68 FBBF  0EC1 ADDE 6EAA 8195 63E9
		  Keygrip = CEA1D8DBCD6DF7DC17AA60A6C7378425CD579569
	uid                   [ultimate] Eric Stewart 
	ssb   rsa4096/0x2821B792843D7A59 2016-04-11 [E] [expires: 2018-04-11]
		  Keygrip = 458BB946CC5E9E41ACBE92756679D267ACB438FD
	ssb   rsa4096/0x695455DC87F1857F 2016-04-11 [S] [expires: 2018-04-11]
		  Keygrip = 5154F53C4F37641819DCEE0FAA3959AD7257A4A5
				
Then send a DELETE_KEY command to the GnuPG Agent using the keygrip of the master secret key:
	PS D:\> gpg-connect-agent "DELETE_KEY CEA1D8DBCD6DF7DC17AA60A6C7378425CD579569" /bye
				
Confirm that you want to delete the key when the agent ask you so.

Step 3: Ensure that the private master key has been removed

List the contents of your private keyring again:

	PS D:\> gpg --list-secret-keys enigelstewart@gmail.com
	sec#  rsa4096/0xADDE6EAA819563E9 2016-04-11 [SC] [expires: 2018-04-11]
		  Key fingerprint = 2968 D18E 6F78 1B68 FBBF  0EC1 ADDE 6EAA 8195 63E9
	uid                   [ultimate] Eric Stewart 
	ssb   rsa4096/0x2821B792843D7A59 2016-04-11 [E] [expires: 2018-04-11]
	ssb   rsa4096/0x695455DC87F1857F 2016-04-11 [S] [expires: 2018-04-11]
				
You should see the # symbol after the sec keyword, confirming that the private master key is not usable.
If you want to be really sure, try to do something that requires the private master key, such as adding a new dummy User ID to your keyring:
	PS D:\> gpg --edit-key enigelstewart@gmail.com
	gpg (GnuPG) 2.1.11; Copyright (C) 2016 Free Software Foundation, Inc.
	This is free software: you are free to change and redistribute it.
	There is NO WARRANTY, to the extent permitted by law.

	Secret key is available.

	pub  rsa4096/0xADDE6EAA819563E9
		 created: 2016-04-11  expires: 2018-04-11  usage: SC
		 trust: ultimate      validity: ultimate
	ssb  rsa4096/0x2821B792843D7A59
		 created: 2016-04-11  expires: 2018-04-11  usage: E
	ssb  rsa4096/0x695455DC87F1857F
		 created: 2016-04-11  expires: 2018-04-11  usage: S
	[ultimate] (1). Eric Stewart 

	gpg> adduid
	Real name: Eric is a dummy
	Email address: EricIs@Dummy.com
	Comment:
	You selected this USER-ID:
		"Eric is a dummy "

	Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
	gpg: signing failed: No secret key
	gpg: signing failed: No secret key

	gpg> quit
				
Note the "signing failed: No secret key" messages.

When to use the offline master key

This master key should be used any time you want to do signing operations with your long-term identity. Examples include:

Your second signing subkey should never be used for any of these things (and in some cases, it's not even possible to do them).

How to use the offline master key

There are several ways to make GnuPG temporarily use the offline master key. The method I am currently using goes along the following lines.
Let’s assume you have stored the enigelstewart-private-keys.asc file (generated in step 1 above) on a USB stick, and that, when the stick is mounted, the file is available at a location such as E:\enigelstewart-private-keys.asc.
Create a temporary directory to use as a temporary GnuPG home, then Import your complete private keyring on that directory from your backup file:

	PS D:\> mkdir gpgtemp
	PS D:\> gpg --homedir .\gpgtemp\ --import E:\enigelstewart-private-keys.asc
	gpg: keybox './gpgtemp//pubring.kbx' created
	gpg: ./gpgtemp//trustdb.gpg: trustdb created
	gpg: key 819563E9: public key "Eric Stewart " imported
	gpg: key 819563E9/819563E9: error sending to agent: No such file or directory
	gpg: error building skey array: No such file or directory
	gpg: Total number processed: 3
	gpg:               imported: 1
	gpg:       secret keys read: 3
				
You may now unmount your USB stick and put it back in its safe place.
Now edit the key you want to sign. Use the temporary directory as GnuPG home, but add the public keyring from your normal GnuPG home directory:
	PS D:\> gpg --homedir .\gpgtemp\ --import C:\Users\Eric\AppData\Roaming\gnupg\pubring.kbx <commands to gpg>
				
Then delete the temp directory once you are done.
I strongly suggest using a small script to automate the above commands. There is such a script here, which is where 95% of these instructions came from: https://incenp.org/notes/2015/using-an-offline-gnupg-master-key.html