There are quite a few other posts on this topic, but my set-up hasn’t been exactly the same as any I found, so I found myself using quite a few resources to achieve exactly what I wanted.
Synopsis
For my personal work, I mostly use GNU/Linux distributions. All of the following operations have been carried out on such platforms and should work on any Debian derivative.
The initial set-up was performed on a machine other than a laptop. Then I discuss the process I took to get my key pairs into a laptop environment.
All keys are created using the RSA cryptosystem.
I’m going to create a large (4096 bit) RSA key-pair as my master (often called primary) key and then create a smaller (2048 bit) key-pair for signing and then another (2048 bit) key-pair for encrypting/decrypting.
Most of the work is done on the command line.
If you haven’t already got gnupg installed (accessed by the gpg command), run the following command as root. More than likely it’s already installed by default though:
apt-get install gnupg
Run gpg from command line. If it’s the first time it’s been run it’ll produce output like the following. This initialises your .gnupg directory and configuration:
gpg: directory `/home/<you>/.gnupg' created gpg: new configuration file `/home/<you>/.gnupg/gpg.conf' created gpg: WARNING: options in `/home/<you>/.gnupg/gpg.conf' are not yet active during this run gpg: keyring `/home/<you>/.gnupg/secring.gpg' created gpg: keyring `/home/<you>/.gnupg/pubring.gpg' created gpg: Go ahead and type your message ...
Just press Ctrl+d to terminate gpg.
Use the sks key-server pool
This section is optional apart from the first three lines that need to be added to the ~/.gnupg/gpg.conf file. The step of using the pool over TLS can of course be done later.
Rather than rely on a single specific key-server and also over an encrypted channel by using the hkps protocol. If a single server is not functioning properly it’s automatically removed from the pool.
In order to use the hkps protocol (hkp over TLS):
sudo apt-get install gnupg-curl
Now you will have a ~/.gnupg/gpg.conf file you can add the following lines to the end of the config file (SHA-1 (the default) is no longer considered secure).
personal-digest-preferences SHA512 cert-digest-algo SHA512 default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP Uncompressed keyid-format 0xlong with-fingerprint
There may be a keyserver and keyserver-options option in the ~/.gnupg/gpg.conf already. If so, modify it, if not, add it.
keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/home/kim/.gnupg/sks-keyservers.netCA.pem
This assumes you downloaded the sks-keyservers.net CA certificate and put it in ~/.gnupg/ . You can of course put it anywhere, but the keyserver-options path will need to reflect your placement.
Verify the certificate’s fingerprint. Compare the fingerprint from the previous link with the output from the following command. It should be the same:
openssl x509 -in sks-keyservers.netCA.pem -fingerprint -noout
Anywhere below where the --keyserver option is specified, can be omitted if you’ve set-up the key-server pool.
Master Key-Pair Generation
This process will create a master key-pair that can be used for signing and a sub key-pair for encrypting/decrypting. We’re actually only going to use the master key-pair that’s created out of this process and we won’t use it for anything other than simply being a master, creating other key-pairs with it, signing other peoples keys etc. We won’t be using it for signing, encrypting/decrypting. We will create two additional sub-keys for this purpose in a bit.
This allows us to remove the master key from our computer and put it in a safe place (disconnected entirely from the network) that can’t be easily accessed. This means that if any of our computers are compromised, the attacker only gets access to our sub-keys which are the keys we use to actually do our day to day work of signing, encrypting outgoing messages and decrypting incoming messages.
On top of this they also need our pass phrase in order to compromise our identity. If in fact an attacker is able to compromise this as well, then we bring our master key out of hiding and can easily revoke the compromised sub key-pair(s) of which the public part is probably on a key-server or your blog or website. This way, when ever anyone gets your public sub-keys from one of the many key-servers or your blog or website, they will see that the public key(s) have been compromised and thus deprecated.
Now run:
gpg --gen-key
Output:
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection?
I chose 1. That’s (1) RSA and RSA (default)
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
Now because this is the master and we’re not actually going to be using it for signing our own messages and encrypting/decrypting and in theory we’ll probably just keep extending it’s expiry date indefinitely, we make it 4096 bit. Why? Because hardware is getting faster all the time and at some stage 2048 bit keys will not be large enough for cryptographic security. Why would we keep extending the master key-pair expiry date? Because we’ve worked hard to acquire other peoples trust (signatures of it) and we don’t really want to go through all that again. That’s why I’ve decided to not actually use the master for day to day work and do everything in my power to make sure it’s never compromised. If somehow the master key-pair was compromised, then I’d still have a revocation certificate that I could use to revoke it. It’d just be a pain though. I go through the creation of the revocation certificate for the master key-pair below.
4096 # Use smaller for sub-keys, as we can replace them easily when it becomes easier to crack them.
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
I chose 5y
Because I want my master key to expire eventually if it’s compromised along with the pass-phrase and somehow I lost the multiple copies of the master revocation certificate. If it never gets compromised, I’ll just keep extending the expiry date.
Key expires at Fri 06 Dec 2019 23:32:56 NZDT Is this correct? (y/N)
I chose:
y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <heinrichh@duesseldorf.de>"
Real name:
Enter your real name:
Kim Carter
Email address:
Enter your email address:
First.Last@provider.com
Comment:
Here you can enter something like your website address or your on-line handle or what ever is useful for providing some more identification
lethalduck
You selected this USER-ID:
"Kim Carter (lethalduck) <First.Last@provider.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
Enter ‘O’ to continue:
O
Now you’re asked for a passphrase. Make this long and hard to guess. I don’t remember this myself. That’s why I use a password vault. To have unique credentials for everything.
You need a Passphrase to protect your secret key.
This is not my passphrase, but it’s a good example of one. Adding the extra characters that are all the same actually makes for a much harder to crack code. Oh, you’ll be prompted to enter this twice.
....................MW$]T&LP[=:[f/8=RQQ0M!++kMreX"....................
Now you’re asked to generate the entropy. This is done by interacting with the computer. keystrokes, mouse movements, storage media work. I find running my rsync scripts now is quite effective.
We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. Not enough random bytes available. Please do some other work to give the OS a chance to collect more entropy! (Need 187 more bytes)
I added a pass phrase and waited for the entropy to be collected.
Once gpg has enough entropy, your key-pairs (master for signing, sub-key for encrypting/decrypting) will be created.
gpg: /home/kim/.gnupg/trustdb.gpg: trustdb created gpg: key F90A5A4E marked as ultimately trusted public and secret key created and signed. gpg: checking the trustdb gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u gpg: next trustdb check due at 2019-12-06 pub 4096R/F90A5A4E 2014-12-07 [expires: 2019-12-06] Key fingerprint = D6B6 1E46 4DC9 A3E9 F450 F7F8 C9FA 6F23 F90A 5A4E uid Kim Carter (lethalduck) <First.Last@provider.com> sub 4096R/65CA12E5 2014-12-07 [expires: 2019-12-06]
Add photo to a uid
Now I wanted to add a photo to my master key-pair.
PGP specifies that the image be no grater than 120×144. GPG recommends it be 240×288. So I chose the smaller size and reduced the quality as much as possible. Could only get it down to 10kb before the image became unrecognisable.
gpg --edit-key F90A5A4E # or safer... gpg --edit-key '<your fingerprint>' # Don't know your fingerprint? gpg --list-keys
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
[ultimate] (1). Kim Carter (lethalduck) <First.Last@provider.com>
gpg>
To add a jpeg:
addphoto
gpg complained that my 10kb image was very large, so I ditched adding the photo.
Add a sub-key for signing
Now before we go any further I just want to make note of the prefixes and suffixes that you’ll often encounter with gpg commands.
Listing your keys with
gpg -K # list secret keys
or
gpg -k # list public keys
will show the following prefixes for your keys.
| sec | === | (sec)ret key |
| ssb | === | (s)ecret (s)u(b)-key |
| pub | === | (pub)lic key |
| sub | === | public (sub)-key |
Roles of the key-pair will be represented by the middle character below.
| Constant | Character | Explanation |
|---|---|---|
| PUBKEY_USAGE_SIG | S | Key is good for signing |
| PUBKEY_USAGE_CERT | C | Key is good for certifying other signatures |
| PUBKEY_USAGE_ENC | E | Key is good for encryption |
| PUBKEY_USAGE_AUTH | A | Key is good for authentication |
When we add sub-keys, they are bound to the master key. The master key is modified to reference the sub-keys
What we want to do is add a sub-key for signing so we can move the master key-pair off of the machine and into a safe place.
We also want to change the expiry date and reduce the size to 2048 of both the new signing sub-key and also create another sub-key for encryption with a shorter expiry date.
Create backup of your ~/.gnupg directory:
umask 077; tar -cf $HOME/gnupg-backup.tar -C $HOME .gnupg
To add a signing sub-key:
gpg --edit-key F90A5A4E # or safer... gpg --edit-key '<your fingerprint>' # Don't know your fingerprint? gpg --list-keys
Output:
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
[ultimate] (1). Kim Carter (lethalduck) <First.Last@provider.com>
gpg>
Now we add the key
addkey
Key is protected. You need a passphrase to unlock the secret key for user: "Kim Carter (lethalduck) <First.Last@provider.com>" 4096-bit RSA key, ID F90A5A4E, created 2014-12-07 Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) Your selection?
Now we want (4) RSA (sign only)
4
Output:
RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048)
Choose 2048 because we can easily regenerate this key-pair or extend the expiry date and at this stage 2048 is secure enough.
2048
Output:
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)
I set this to 2y
Key expires at Wed 07 Dec 2016 01:21:11 NZDT Is this correct? (y/N)
y
Really create? (y/N)
y
After this gpg collects more entropy. When it’s done it dumps you back to the gpg prompt
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 186 more bytes)
.......+++++
.+++++
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
[ultimate] (1). Kim Carter (lethalduck) <First.Last@provider.com>
gpg>
Now you can see from the ‘S’ suffix that we do now have a sub-key that’s “good for signing”
Same again but for encrypting
While still at the gpg prompt, run addkey again but choose option 6.
That’s (6) RSA (encrypt only)
Choose 2048 for the keysize.
Choose 2y (two years) for how long the key is valid for.
Eventually you’ll see:
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
sub 2048R/8FF9669C created: 2014-12-07 expires: 2016-12-06 usage: E
[ultimate] (1). Kim Carter (lethalduck) <First.Last@provider.com>
gpg>
Now you can see from the ‘E’ suffix that we do now have a sub-key that’s “good for encryption”
To save the new keys before finishing with gpg, type save.
Create Revocation Certificate for Master Key
gpg --output F90A5A4E.gpg-revocation-certificate --gen-revoke F90A5A4E
Output:
sec 4096R/F90A5A4E 2014-12-07 Kim Carter (lethalduck) <First.Last@provider.com> Create a revocation certificate for this key? (y/N)
Type y
Please select the reason for the revocation: 0 = No reason specified 1 = Key has been compromised 2 = Key is superseded 3 = Key is no longer used Q = Cancel (Probably you want to select 1 here) Your decision?
Type 1
Enter an optional description; end it with an empty line: >
Enter anything you like here.
This revocation certificate was generated when the key was created. >
Reason for revocation: Key has been compromised This revocation certificate was generated when the key was created. Is this okay? (y/N)
y
Output:
You need a passphrase to unlock the secret key for user: "Kim Carter (lethalduck) <First.Last@provider.com>" 4096-bit RSA key, ID F90A5A4E, created 2014-12-07 ASCII armored output forced. Revocation certificate created. Please move it to a medium which you can hide away; if Mallory gets access to this certificate he can use it to make your key unusable. It is smart to print this certificate and store it away, just in case your media become unreadable. But have some caution: The print system of your machine might store the data and make it available to others!
Now store your master key-pair revocation certificate somewhere off of the network. Preferably in more than one place also.
Copy ~/.gnupg to an external device (/media/) for safe keeping before we remove the master key-pair from your computer.
Remove master key
Following are the commands to do this.
gpg --export-secret-subkeys F90A5A4E > /media/<your encrypted USB device>/subkeys
gpg --delete-secret-key F90A5A4E
Output:
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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. sec 4096R/F90A5A4E 2014-12-07 Kim Carter (lethalduck) <First.Last@provider.com> Delete this key from the keyring? (y/N)
Type y
This is a secret key! - really delete? (y/N)
Type y
gpg --import /media/<your encrypted USB device>/subkeys
Output:
gpg: key F90A5A4E: secret key imported gpg: key F90A5A4E: "Kim Carter (lethalduck) <First.Last@provider.com>" not changed gpg: Total number processed: 1 gpg: unchanged: 1 gpg: secret keys read: 1 gpg: secret keys imported: 1
Now check to make sure that the master key-pair is no longer on your computer but is on your USB device:
gpg -K
Output:
sec# 4096R/F90A5A4E 2014-12-07 [expires: 2019-12-06] uid Kim Carter (lethalduck) <First.Last@provider.com> ssb 4096R/65CA12E5 2014-12-07 ssb 2048R/7A3122BD 2014-12-07 ssb 2048R/8FF9669C 2014-12-07
gpg --home=/media/<your encrypted USB device>/.gnupg/ -K
Output:
sec 4096R/F90A5A4E 2014-12-07 [expires: 2019-12-06] uid Kim Carter (lethalduck) <First.Last@provider.com> ssb 4096R/65CA12E5 2014-12-07 ssb 2048R/7A3122BD 2014-12-07 ssb 2048R/8FF9669C 2014-12-07
You can see that the first command shows sec#. This means there is no master key-pair in your ~/.gnupg/ directory.
Upload your Public Keys to KeyServer
Remember if you used a key-server pool, anywhere the --keyserver option is specified, can be omitted.
I’ve chosen https://pgp.mit.edu/
You can choose any public keyserver. They all communicate with each other and sync updates at least daily. You can also send more than one public key by adding additional Ids after the –send-keys.
gpg --keyserver hkp://pgp.mit.edu/ --send-keys F90A5A4E
Output:
gpg: sending key F90A5A4E to hkp server pgp.mit.edu
Download public keys from KeyServer
gpg --keyserver hkp://pgp.mit.edu/ --recv-keys <key id to receive and merge signatures>
A safer way to do this is to not just trust every key from a key-server, but rather to verify the key belongs to who you think it belongs to before you download and trust it. Try one at a time and use the fingerprint rather than just the short Id.
gpg --keyserver hkp://pgp.mit.edu/ --recv-key '<fingerprint>'
The single quotes are mandatory around the fingerprint. Double quotes will also work.
Refreshing local Keys from Key-Server
gpg --refresh-keys
Set-up the Laptop with your key-pairs
Copy the contents of the desktops ~/.gnupg/ to the laptops ~/.gnupg/ . I just used the same USB drive for this, but made sure I didn’t mix this .gnupg/ up with the one that had the master key. Then delete the copy without the master key once copied to save any confusion. Also keep in mind that when you delete files from a flash drive they are not actually deleted. That’s why it’s important to use an encrypted USB drive. Also keep it in a very safe place, make a copy of it and keep that off site in a very safe place also.
Make sure you check the permissions of the ~/.gnupg files you just copied to the laptop so that they are the same as the files crated with the gpg command.
Adding another E-Mail Address
Now it’s easier if you do this here in the sequence, but I didn’t think about it until after I’d uploaded the public keys. If you do want to add another uid once you’ve moved the master key, copied your master key’less sub-keys to your laptop, it just means you’ve got to operate on the master key that you moved into /media//.gnupg/, then copy the contents of /media//.gnupg/ back to ~/.gnupg/ on both your desktop and laptop machines not forgetting to change file permissions again, remove master key from ~/.gnupg/ and upload the modified public keys again.
This is how you would add the additional uid:
gpg --home=/media/<your encrypted USB device>/.gnupg --edit-key F90A5A4E # or safer... gpg --home=/media/<your encrypted USB device>/.gnupg --edit-key '<your fingerprint>' # Don't know your fingerprint? gpg --list-keys
Output:
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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.
gpg: DBG: locking for `/media/<your encrypted USB device>/.gnupg/trustdb.gpg.lock' done via O_EXCL
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
sub 2048R/8FF9669C created: 2014-12-07 expires: 2016-12-06 usage: E
[ultimate] (1). Kim Carter (lethalduck) <First.Last@provider.com>
gpg>
Add the extra uid now:
adduid
Output:
Real name:
Enter your real name:
Kim Carter
Output:
Email address:
Enter the additional email address you want:
kim.carter@owasp.org
Output:
Comment:
Add the web page that adds some proof of identity:
https://www.owasp.org/index.php/New_Zealand
Output:
You selected this USER-ID:
"Kim Carter (https://www.owasp.org/index.php/New_Zealand) <kim.carter@owasp.org>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?
Type O
Output:
You need a passphrase to unlock the secret key for
user: "Kim Carter (lethalduck) <First.Last@provider.com>"
4096-bit RSA key, ID F90A5A4E, created 2014-12-07
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
sub 2048R/8FF9669C created: 2014-12-07 expires: 2016-12-06 usage: E
[ultimate] (1) Kim Carter (lethalduck) <First.Last@provider.com>
[ unknown] (2). Kim Carter (https://www.owasp.org/index.php/New_Zealand) <First.Last@owasp.org>
gpg>
Now we want the same trust level applied to the second uid as the existing:
trust
Output:
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
sub 2048R/8FF9669C created: 2014-12-07 expires: 2016-12-06 usage: E
[ultimate] (1) Kim Carter (lethalduck) <First.Last@provider.com>
[ unknown] (2). Kim Carter (https://www.owasp.org/index.php/New_Zealand) <First.Last@owasp.org>
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision?
Type 5
Output:
Do you really want to set this key to ultimate trust? (y/N)
Type y
Output
pub 4096R/F90A5A4E created: 2014-12-07 expires: 2019-12-06 usage: SC
trust: ultimate validity: ultimate
sub 4096R/65CA12E5 created: 2014-12-07 expires: 2019-12-06 usage: E
sub 2048R/7A3122BD created: 2014-12-07 expires: 2016-12-06 usage: S
sub 2048R/8FF9669C created: 2014-12-07 expires: 2016-12-06 usage: E
[ultimate] (1) Kim Carter (lethalduck) <First.Last@provider.com>
[ unknown] (2). Kim Carter (https://www.owasp.org/index.php/New_Zealand) <First.Last@owasp.org>
gpg>
Don’t worry that it still looks like it’s unknown. Once you save and try to edit again, you’ll see the change has been saved.
If you want to make the uid that you’ve tentatively just added your primary, select it:
uid 2
issue the command:
primary
and finally save:
save
Sign Someone Else’s Public Key
You’re going to have to download, import the persons key into your ~/.gnupg/pubring.gpg
If you’ve got a key-server pool configured, you won’t need the --keyserver option.
gpg --recv-key '<fingerprint of public key you want to import>'
gpg --home=/media/<your encrypted USB device>/.gnupg/ --primary-keyring=~/.gnupg/pubring.gpg --sign-key '<fingerprint of public key you want to sign>'
There will be some other output here. I wasn’t actually asked which trust level I wanted to provide, so I carried out the following edit.
gpg --edit-key '<fingerprint of public key you want to sign>'
Output:
gpg (GnuPG) 1.4.16; Copyright (C) 2013 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.
pub 4096R/<id of public key you just signed> created: 2014-05-09 expires: never usage: SC
trust: unknown validity: unknown
sub 4096R/<a sub-key> created: 2014-05-09 expires: never usage: E
sub 4096R/<another sub-key> created: 2014-05-09 expires: 2019-05-08 usage: S
[ unknown] (1). <key holders name> (4096 bit key generated 9/5/2014) <e-mail1@gmail.com>
[ unknown] (2) <key holders name> (Their key) <e-mail@somethingelse.com>
[ unknown] (3) <key holders name> (Their Yahoo) <e-mail@yahoo.com>
[ unknown] (4) <key holders name> (Their Other Email Account) <e-mail@whatever.org>
gpg>
Issue the trust command:
trust
Output:
pub 4096R/<id of public key you just signed> created: 2014-05-09 expires: never usage: SC
trust: unknown validity: unknown
sub 4096R/<a sub-key> created: 2014-05-09 expires: never usage: E
sub 4096R/<another sub-key> created: 2014-05-09 expires: 2019-05-08 usage: S
[ unknown] (1). <key holders name> (4096 bit key generated 9/5/2014) <e-mail1@gmail.com>
[ unknown] (2) <key holders name> (Their key) <e-mail@somethingelse.com>
[ unknown] (3) <key holders name> (Their Yahoo) <e-mail@yahoo.com>
[ unknown] (4) <key holders name> (Their Other Email Account) <e-mail@whatever.org>
Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)
1 = I don't know or won't say
2 = I do NOT trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
m = back to the main menu
Your decision?
3
Output:
pub 4096R/<id of public key you just signed> created: 2014-05-09 expires: never usage: SC
trust: marginal validity: unknown
sub 4096R/<a sub-key> created: 2014-05-09 expires: never usage: E
sub 4096R/<another sub-key> created: 2014-05-09 expires: 2019-05-08 usage: S
[ unknown] (1). <key holders name> (4096 bit key generated 9/5/2014) <e-mail1@gmail.com>
[ unknown] (2) <key holders name> (Their key) <e-mail@somethingelse.com>
[ unknown] (3) <key holders name> (Their Yahoo) <e-mail@yahoo.com>
[ unknown] (4) <key holders name> (Their Other Email Account) <e-mail@whatever.org>
Please note that the shown key validity is not necessarily correct
unless you restart the program.
gpg>
Email the Signed Public-Key
In order to send an email with the freshly signed public-key, attach the file generated with the following command, encrypt and send the email to the owner of the public key specified by their uid. Details on how to encrypt the e-mail are specific to the e-mail client you choose to use.
gpg --armor --output <long id of receivers public key>.signed-by.0xc9fa6f23f90a5a4e --export '<fingerprint of public key you just signed>'
Upload the Signed Public-Key to a Key Server
gpg --send-key '<fingerprint of public key you just signed>'
Output:
gpg: sending key <long id of receivers public key> to hkps server hkps.pool.sks-keyservers.net
Verify to make sure you’re public domain signing is good.
Import Your Public-Key Signed by Someone Else
At some stage you may need to import a copy of your public-key in the form of a file that someone else has added their signature to
gpg --import ./0xC9FA6F23F90A5A4E.signed-by-<someone else's long id>.asc
Then view your new signatures:
gpg --list-sigs 0xC9FA6F23F90A5A4E
Then upload them again with --send-key
and pull them down to your other machines with --refresh-keys. You’ll also need to --recv-key their keys so that your key recognises who the signatories are. Or… just simply copy over your ~/.gnupg/ directory. Make sure to check your permissions before and after the copy though. We don’t want anyone other than you being able to read these files. Especially the secring.gpg and any pem certs you have.
Browser based E-Mail
Two browser extensions that look OK are:
- Mailvelope for Firefox and Chrome (I’m using this)
Getting set-up details
Details of how this works here - Mymail-Crypt for Gmail
Desktop based E-Mail
Thunderbird with enigmail
I also found that to send or reply to someone and encrypt, that I had to make a change in Thunderbird, as Thunderbird wrongly thinks I’m not trusting identities when I have specifically set trust levels. I’ve heard comments that if you set the trust level in gpg to “I trust ultimately” then Enigmail is happy to send your mail. I only trust myself ultimately so I found another way.
If you go into the Edit menu of Thunderbird -> Account Settings. For each email account in your gpg signature… OpenPGP Security -> Enigmail Preferences… -> Change “To send encrypted, accept” from Only trusted keys to “All usable keys”. Then when you get the final confirmation of sending encrypted email, you are asked to confirm the 8 digit ID. I just double check by
gpg --edit-key '<keyID that Thunderbird says it's using>'
Additional Resources I’ve Collected
Posts/articles, Documentation
- Kiwicon key signing party run-down
- GnuPG Keys
- new GPG key with sub-keys
- Debian wiki sub-keys
- Keysigning with GNU/Linux Terminal
- GNUPG docs: Protecting your private key
- gpg man page
- Changing the expiration date of GPG keys
Podcasts
- HPR GPG and E-Mail
- HPR Encrypting E-Mail on Android
- Setting up GnuPG
- Creating a Key Pair using GUI Client
- FOSDEM Key-signing Event
- Encryption and E-Mail with Thunderbird
Tags: encryption, GPG, Security
Binarymist 
Leave a Reply