If you’ve recently completed a key signing party or have otherwise met up with other people and have exchanged key fingerprints and verified IDs, it’s now time to sign the keys you trust. There are several different ways of completing this task and I’ll discuss two of them now.
CA Fire and Forget (caff) is a program that allows you to sign a bunch of keys (like you might have after a key signing party) very quickly. It also adds a level of security to the signing process by forcing the other person to verify that they have both control over the email address provided and the key you signed. The way caff does this is by encrypting the signature in an email and sending it to the person. The person who receives the message must also decrypt the message and apply the signature themselves. Once they sync their key with the key server the new signatures will appear for everyone.
$ gpg --keyserver hkp://pool.sks-keyservers.net --refresh-key
There is some setup of caff that needs to be done prior but once you have it setup it’ll be good to go.
Installing caff is pretty easy although there might be a little trick. In Fedora there isn’t a caff package. Caff is actually in the pgp-tools package; other distros may have this named differently.
Once you have caff installed and setup, you just need to tell caff what key IDs you would like to sign. “man caff” will give you all the options but basically ‘caff -m
no yes -u ‘ will sign all the keys listed after your key. You will be asked to verify that you do want to sign the key and then caff will sign the key and mail it off. The user will receive an email, per user id on the key, with instructions on importing the signature.
Signing a key with GnuPG
The other way of signing a PGP key is to use GnuPG. Signing a key this way will simply add the signature to the key you have locally and then you’ll need to send those keys out to the key server.
Retrieving keys using GnuPG
The first thing that you have to do is pull the keys down from the keyserver.
$ gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys ...
Once you have received all the keys you can then sign them. If someone’s key is not there you should probably contact them and ask them to add their key to the servers. If they already have uploaded their key, it might take a couple of hours before it is sync’d everywhere.
Signing a key is pretty straightforward:
$ gpg --sign-key 1bb943db pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC trust: unknown validity: unknown sub 4096g/672557E6 created: 2010-02-02 expires: never usage: E [ unknown] (1). MariaDB Package Signing Key <firstname.lastname@example.org> [ unknown] (2) Daniel Bartholomew (Monty Program signing key) <email@example.com> Really sign all user IDs? (y/N) y pub 1024D/1BB943DB created: 2010-02-02 expires: never usage: SC trust: unknown validity: unknown Primary key fingerprint: 1993 69E5 404B D5FC 7D2F E43B CBCB 082A 1BB9 43DB MariaDB Package Signing Key <firstname.lastname@example.org> Daniel Bartholomew (Monty Program signing key) <email@example.com> Are you sure that you want to sign this key with your key "Eric Harlan Christensen <firstname.lastname@example.org>" (024BB3D1) Really sign? (y/N) y
In the example I signed the MariaDB key with my key. Once that is complete a simple:
gpg --keyserver hkp://pool.sks-keyservers.net --send-key 1BB943DB
…will send the new signature to the key servers.
Generating a PGP using GnuPG (GPG) is quite simple. The following shows my recommendations for generating a PGP key today.
$ gpg --gen-key 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? 1 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 3072 Requested keysize is 3072 bits Please specify how long the key should be valid. 0 = key does not expire = key expires in n days w = key expires in n weeks m = key expires in n months y = key expires in n years Key is valid for? (0) 1y Key expires at Tue 16 Jun 2015 10:32:06 AM EDT Is this correct? (y/N) 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) <email@example.com>"
Real name: Given Surname Email address: firstname.lastname@example.org Comment: Example You selected this USER-ID: "Given Surname (Example) <email@example.com>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o You need a Passphrase to protect your secret key.
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. ..........+++++ .....+++++ 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. +++++ ....+++++ gpg: key 2CFA0010 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: 2 signed: 49 trust: 0-, 0q, 0n, 0m, 0f, 2u gpg: depth: 1 valid: 49 signed: 60 trust: 48-, 0q, 0n, 0m, 1f, 0u gpg: depth: 2 valid: 8 signed: 17 trust: 8-, 0q, 0n, 0m, 0f, 0u gpg: next trustdb check due at 2014-09-09 pub 3072R/2CFA0010 2014-06-16 [expires: 2015-06-16] Key fingerprint = F81D 16F8 3750 307C D090 4DC1 4D05 E6EF 2CFA 0010 uid Given Surname (Example) <firstname.lastname@example.org> sub 3072R/48083419 2014-06-16 [expires: 2015-06-16]
The above shows the complete exchange between GPG and myself. I’ll point out a couple of selections I made and explain why I made those choices.
Key type selection
I selected the default selection of two RSA keys. The keys used for signing and encryption will both be RSA which is strong right now. DSA has been proven to be weak in certain instances and should be avoided in this context. I have no comment on ElGamal as I’ve not done research here. Ultimately the choice is up to you.
I’ve selected 3072 instead of the default 2048 here. I recommend this as the minimum bit strength as this provides 128 bits of security as compared to 112 bits of security with 2048. 128 bits of security should be secure beyond 2031 as per NIST SP 800-57, Part 1, Rev 3.
By default, I make my keys expire after a year. This is a fail-safe and can be later modified before the expiration to extend the expiration another year. This makes sure the key will self destruct if you ever lose control of it.
You’ll now be asked to add your name and email address. This should be self-explanatory.
Once you have completed your key generation now is the time to generate the key revocation file. If you ever lose control of your key you should immediately upload this file to the public key servers so everyone using your key will know that it has [potentially] been compromised. Once you’ve generated this revocation just keep it somewhere safe. You can even print it out and keep it locked up somewhere. It’s important to do this this ahead of time as you may not be able to do this later. You’ll obviously want to substitute your own keyid for 2CFA0010.
$ gpg --gen-revoke 2CFA0010
sec 3072R/2CFA0010 2014-06-16 Given Surname (Example) <email@example.com>
Create a revocation certificate for this key? (y/N) 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? 1 Enter an optional description; end it with an empty line: > Reason for revocation: Key has been compromised (No description given) Is this okay? (y/N) y
You need a passphrase to unlock the secret key for user: "Given Surname (Example) <firstname.lastname@example.org>" 3072-bit RSA key, ID 2CFA0010, created 2014-06-16
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! -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1 Comment: A revocation certificate should follow
iQGfBCABAgAJBQJTnwtaAh0CAAoJEE0F5u8s+gAQHMQMANH1JG5gVDnp5NY4o8ji 3j6GljQ9ieY+u3c5q0c08/uSAqGvL9jmPn1QAnikAkIJGy9kNmBJ/uC6pSMcHeCW /vYWMD/cToy63tgLOf4A8GgX2k8ttFe+DpFFSt43zbGVowykZ5AHwKImtyFwVO7M IKQZV21uFcIDl7jb5GkymkpWRZmIrexOyIAQjpyYWQT4BFFnI7kwpYyVbmodkwE/ JaC0d5dMVT9DRLr5FGuGSpzYJEeB14GCjT2EQ1js/Bji2fguFqpzM5z77FdzhS7s SNGgY8bioyjUN3CsyHMfPpkJi9mBDCV4gTxyLlVOdDiSdqA56mzjvrx3tnltfjyN kFJfPDWLqXFNpzX516oOo37b3P92bSEPcIgGeTL58nVUn/BWMsoDlIbwNyjxx7Tq YYXa2T2rbH1JHndOrmAc9X98cNrhs+vppV6SBev2MnvqobT2nqW7hKeNvwIyqunF 79fL9En2p57pQ8vH4EeRhjFSciuZZBpCEv2cMIDQGMFKVQ== =6ljf -----END PGP PUBLIC KEY BLOCK-----
Proper key storage
Generally speaking, your private PGP key is stored on your computer encrypted. It is protected by your normal security measures of your computer and whatever password you set. There is a better way. Use a hardware security module (HSM) like a Yubikey Neo, OpenPGP card, or CryptoStick to protect your private key from disclosure.
Publishing your public key
Now that you have your PGP keys you’ll want to publish your public key to the key servers so others can easily obtain it to validate your signatures.
$ gpg --keyserver hkps://hkps.pool.sks-keyservers.net --send-keys 2CFA0010
You’ll obviously want to substitute your own keyid for 2CFA0010. This command will send your key to the SKS public key servers which will then replicate your key around the world in a few hours.
Someone recently asked what my GPG.conf file looks like since he hadn’t updated his in… years. Okay, let’s take a look and I’ll try to explain what each setting is and why I feel it is important. I’m not guaranteeing this as being complete and I welcome input from others.
This says that if a program needs a public key but it’s not in my keyring that it should automatically reach out to the keyserver (see below) and download it.
This says to use the GPG agent. I cannot remember, right now, why this was a good idea. Perhaps it isn’t?
auto-key-locate cert pka ldap hkps://hkps.pool.sks-keyservers.net keyserver hkps://hkps.pool.sks-keyservers.net keyserver-options ca-cert-file=/etc/ssl/certs/sks-keyservers.netCA.pem keyserver-options no-honor-keyserver-url keyserver-options auto-key-retrieve
Almost the fun stuff there. This is just setting up the keyserver that I wish to use (note the use of hkps instead of hkp).
default-preference-list AES AES192 AES256 TWOFISH SHA1 SHA224 SHA256 SHA384 SHA512 Uncompressed ZIP ZLIB BZIP2 personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 SHA224 personal-compress-preferences BZIP2 ZLIB ZIP
Okay, the fun stuff. These are all the algorithms that I wish to use. If you setup your GPG key to advertise these then it will make it easier for others to use the most secure algorithms since they will already know what you can do. The first line just lists all the preferences. The second, third, and fourth lines actually provide the preferences in order of them being used. If you’ll note my preferred cipher is AES with a 256-bit key and my preferred hash (digest) is SHA with a 512-bit key. There are other options available and a quick
should provide what options are available to you. For instance, my current installation says that its supported algorithms are:
Pubkey: RSA, RSA-E, RSA-S, ELG-E, DSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
I’ve omitted 3DES, MD5, and SHA1 from my preferences due to their weaknesses but I could still use them according to my GnuPG software.
Again, this wasn’t meant to be a strict “thou must do this to be secure” but rather a “this is what I’m doing” sort of thing. I’d appreciate feedback!
I was recently introduced to a privacy issue when refreshing your OpenPGP keys using GnuPG. When refreshing your public key ring using a public key server GnuPG will generally use the OpenPGP HTTP Key Protocol (HKP) to synchronize keys. The problem is that when you do refresh your keys using HKP everyone that you maintain in your public key ring is sent across the Internet unencrypted. This can allow anyone monitoring your network traffic to receive a complete list of contacts in which you may hope to use OpenPGP.
The fix is quite simple: in your gpg.conf file make sure that your keyserver entries include hkps:// instead of hkp://. This will force GnuPG to wrap HKP in SSL to keep the key exchange private.
So this poll is a bit stale but the information is interesting nonetheless.
So what do these poll results mean, exactly? Well, scientifically not much. I mean, I guess we could make some sort of scientific bearing here. Let’s try:
So of the people responding to the completely voluntary poll on this not-so-well-read blog and felt the need to respond, a vast majority have setup OpenPGP or GnuPG and over half use it on at least a semi-regular basis. That’s encouraging, really, that of the 72 respondents, 42 of you use your keys somewhat regularly and are protecting yourself.
I wonder about the 10 people that responded that you have keys but never use them. Why is this? You’ve come so far to not use the technology that’s been provided!
So this was fun. Perhaps I’ll find another question to ask where I won’t forget that I asked it.
I created my web of trust graphic (select the graphic to zoom in to see detail) this morning showing the additions from the key-signing event at FUDCon Lawrence. I’m also working on building the Fedora web of trust and I may do one for Red Hat as well.
If you’d like to create your own web of trust graphic you can follow the instructions on Aaron Toponce’s website.
Earlier I announced a new PGP key. The decision was made based on my inability to correctly revoke certain uids on my key. I finally figured out my problem and have revoked many of the uids on my key that no longer valid or were no longer being used. So I hope no one wrote off my old key just yet. I’ve had it for a while and I kinda like it. You may want to update it from either my website (see top of the page on this site) or via one of the many keyservers. Sorry for the noise.
I’ve created a new OpenPGP key (0x08CC129D) to replace the one I’ve used for the past few years (0x024BB3D1). Please update your keyrings as necessary.Nope, I’ve decided to keep my old key and just clean it up a bit.
Last year’s OpenPGP key signing and CAcert assertion events at FUDCon Blacksburg were a great success; we hope this year’s events will be just as popular and well attended. If you are coming to FUDCon Lawrence and would like to participate in the either or both of these events please sign up on the wiki pages. Additional information will be provided as the event gets closer. It’s important to sign up for these events early as it will make planning easier for us.