After years of using caff for my PGP key-signing needs I finally come across the answer to a question I’ve had since the beginning. I document it here so that I may keep my sanity next time I go searching for the information.
My question was “how do you make a specific certification in a signature?”. As defined in RFC 1991, section 6.2.1, the four types of certifications are:
<10> - public key packet and user ID packet, generic certification ("I think this key was created by this user, but I won't say how sure I am") <11> - public key packet and user ID packet, persona certification ("This key was created by someone who has told me that he is this user") (#) <12> - public key packet and user ID packet, casual certification ("This key was created by someone who I believe, after casual verification, to be this user") (#) <13> - public key packet and user ID packet, positive certification ("This key was created by someone who I believe, after heavy-duty identification such as picture ID, to be this user") (#)
Generally speaking, the default settings in caff only provide the first level “generic” certification. Tonight I found information specific to ~/.caff/gnupghome/gpg.conf. This file can contain, as far as I know, can contain three lines:
I can’t find any official information on this file as the man pages are a little slim on details. That said, if you use caff you should definitely create this file and populate it with the above at a minimum with the exception of the default-cert-level. The default-cert-level should be whatever you feel comfortable setting this as. My default is “2″ for key signing parties (after I’ve inspected an “official” identification card and/or passport). The other two settings are important as they provide assurances of using a decent SHA-2 hash instead of the default
I went to sign an outgoing message tonight and my Gemalto USB Shell Token wouldn’t light up when I plugged it into my USB port. After doing the typical troubleshooting I am left with the thought that the device has given up the ghost. This isn’t a big problem because I saved the card the SIM came out of and I’m able to use my token on my personal laptop with a traditional card reader. My work computer, however, does not have one of these fancy card readers (maybe I can find my USB one somewhere?).
I can buy another Gemalto device but I’m wondering if there is a better device to use? I mean, the Gemalto lasted almost 500 signatures. But I guess I can now take advantage of the failure to try something else. Does anyone have any suggestions?
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.
If your email messages are being signed using SHA-1 you may not be getting the security you think you are. Attacks on the hashing algorithm have caused much pain to those that use it. Luckily SHA-2 is available and hopefully we’ll start seeing SHA-3 out in the world soon.
You’ve probably already seen SHA-2 in the wild designated as SHA-224, SHA-256, SHA-384, and SHA-512. Because of the weaknesses found in SHA-1 it’s important to not use that algorithm any longer. That means when you generate hashes you shouldn’t use sha1sum but rather one of the SHA-2 tools: sha224sum, sha256sum, sha384sum, or sha512sum. Depending on the length of time you need to protect the data the strength of the hash will be important. A larger key will be more secure for a longer period of time than a shorter one.
GNU Privacy Guard (GPG) has a default of using SHA-1, however, unless you manually select another algorithm in your gpg.conf file (usually found in ~/.gnupg). To use something other than the default you should add the following lines:
personal-cipher-preferences AES256 TWOFISH AES192 AES personal-digest-preferences SHA512 SHA384 SHA256 personal-compress-preferences ZLIB BZIP2 ZIP
These lines establish not only the preferences for which algorithms to use (for cipher, digest (hashing), and compression) but also in what order to use them. You can determine what algorithms are available to you by asking GPG in the command line:
$ gpg --version ... Home: ~/.gnupg Supported algorithms: Pubkey: RSA, ELG, DSA Cipher: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256 Hash: MD5, SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224 Compression: Uncompressed, ZIP, ZLIB, BZIP2
GPG will show specifically what is supported based on what’s built into the code when the package was built.
Using the proper algorithm is important for maintaining a secure communications environment so do your research and use something in which you feel comfortable.
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.
I run a SKS key server and watch my daily numbers to see how many keys get updated, etc. Being a numbers guy I wondered how many people, like me, update their GPG keys, I specifically update the expiration date and generate new encryption keys annually, at the beginning of the new year. Apparently I’m not alone:
|Time||New Keys||Updated Keys|
Specifically these keys were updated at 1700Z. I’m not sure I have the ability to see which keys were updated but I’d love to know how that happened.
If you are planning on attending the FUDCon Blacksburg PGP (GnuPG) Key Signing Event please go to the event page and sign up now. Additional instructions will be sent to you as we get closer to the event date.
Hope to see everyone there!
I, unfortunately, will not be in attendance to join this event but I did want help advertise this event. While the Fedora Web of Trust (WoT) is getting its act together you can start participating immediately! FUDcon Pune is hosting a keysigning event on 05 November 2011. If you are available please go and get your key signed and sign other people’s keys so the trust can build.
Hope everyone has a great time in Pune!