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.
My friend Hubert has started compiling statistics of Alexa’s top 1 million websites. Specifically, he’s looking at their SSL/TLS settings and attempting to show trends in the world that is port 443. He recently released his May numbers showing a slow but mostly improving security environment. I’m hoping he’ll be able to chart these trends in a way to make it easier for people to consume the data and be able to dynamically look for data that they are interested in. I guess we’ll have to wait and see what come about. Until then I believe he’ll continue to post his monthly numbers on the Fedora Security List.
This is an incomplete discussion of SSL/TLS authentication and encryption. This post only goes into RSA and does not discuss DHE, PFS, elliptical, or other mechanisms.
In a previous post I created an 15,360-bit RSA key and timed how long it took to create the key. Some may have thought that was some sort of stunt to check processor speed. I mean, who needs an RSA key of such strength? Well, it turns out that if you actually need 256 bits of security then you’ll actually need an RSA key of this size.
According to NIST (SP 800-57, Part 1, Rev 3), to achieve 256 bits of security you need an RSA key of at least 15,360 bits to protect the symmetric 256-bit cipher that’s being used to secure the communications (SSL/TLS). So what does the new industry-standard RSA key size of 2048 bits buy you? According to the same document that 2048-bit key buys you 112 bits of security. Increasing the bit strength to 3072 will bring you up to the 128 bits that most people expect to be the minimum protection. And this is assuming that the certificate and the certificate chain are all signed using a SHA-2 algorithm (SHA-1 only gets you
80 60 bits of security when used for digital signatures and hashes).
So what does this mean for those websites running AES-256 or CAMELLIA-256 ciphers? They are likely wasting processor cycles and not adding to the overall security of the circuit. I’ll make two examples of TLS implementations in the wild.
First, we’ll look at wordpress.com. This website is protected using a 2048-bit RSA certificate, signed using SHA256, and using AES-128 cipher. This represents 112 bits of security because of the limitation of the 2048-bit key. The certificate is properly chained back to the GoDaddy CA which has a root and intermediate certificates that are all 2048 bits and signed using SHA-256. Even though there is a reduced security when using the 2048-bit key, it’s likely more efficient to use the AES-128 cipher than any other due to chip accelerations that are typically found in computers now days.
Next we’ll look at one of my domains: christensenplace.us. This website is protected using a 2048-bit RSA certifcate, signed using SHA-1, and using CAMELLIA-256 cipher. This represents
80 60 bits of security due to the limitation of the SHA-1 signature used on the certificate and the CA and intermediate certificates from AddTrust and COMODO CA. My hosting company uses both the RC4 cipher and the CAMELLIA-256 cipher. In this case the CAMELLIA-256 cipher is a waste of processor since the certificates used aren’t nearly strong enough to support such encryption. I block RC4 in my browser as RC4 is no longer recommended to protect anything. I’m not really sure exactly how much security you’ll get from using RC4 but I suspect it’s less than SHA-1.
So what to do? Well, if system administrators are concerned with performance then using a 128-bit cipher (like AES-128) is a good idea. For those that are concerned with security, using a 3072-bit RSA key (at a minimum) will give you 128 bits of security. If you feel you need more bits of security than 128 then generating a solid, large RSA key is the first step. Deciding how many bits of security you need all depends on how long you want the information to be secure. But that’s a post for another day.
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:
ask-cert-level <- works in lieu of the default-cert-level to ask you on each signature
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’ve been arguing with my web hosting company about their use of RC4. Like many enterprise networks they aren’t consistent across all their servers with respect to available ciphers and such. It appears that all customer servers support TLS_RSA_WITH_CAMELLIA_256_CBC_SHA and TLS_RSA_WITH_CAMELLIA_128_CBC_SHA, in addition to TLS_RSA_WITH_RC4_128_SHA (although the latter is preferred over the other two) but their backend controlling web servers only support RC4. This is a problem if you are handling crypto (keys) (and other settings) over a weak encryption path to better secure your web service as you have essentially failed due to using the weak encryption to begin with.
So what’s wrong with RC4?
It’s been known for a while (years!) that RC4 is not a good encryption cipher. It’s broken and there are several attacks that are available. So why is it being used so frequently? In a word: BEAST. RC4 was the only stream cipher available that can combat BEAST and so it became the standard for all TLS connections. It’s not clear which attack vector is worse: BEAST or the weak RC4.
In recent months most Internet browsers have implemented the workaround n/n-1 to fix the BEAST vulnerability. With the fix in place it should, once again, be safe to use block ciphers and, thus, get better encryption ciphers (better protection). There have been many people and organizations talking about the need to get rid of RC4 now since it is a bigger threat to web security. Yesterday Microsoft released a security bulletin discussing the problem and urged all developers to stop using RC4. (Oh yeah, and they also want to stop using SHA-1 as well.) I usually think of Microsoft as trailing in the security field (lets face it, their products aren’t known for being secure ever since that whole network thing happened) so when they say that this mess with RC4 must stop it’s gotten to a point where we should have already done so.
So what are we waiting for?
I think, simply, we’re waiting for TLSv1.1 and TLSv1.2 to become mainstream. It’s not as if these technologies have just popped up on our radar screens, however, (they’ve been out since April 2006 and August 2008, respectfully) but there has been slow adoption of the two flavors of TLS. According to Microsoft, their products are ready for TLSv1.1 and TLSv1.2 (both IIS on and IE 11+). Firefox supports up to TLSv1.2 in 25.0 but you have to manually turn it on (it’s for testing) and OpenSSL (used for Apache) should support TLSv1.2 in its 1.0.1e release. It’s time to start pushing these better encryption mechanisms into operation… now.
Thought I’d pass along this research study, The keys to the kingdom, as I found it to be quite interesting (especially when you scan the entire Internet for your data). If you don’t understand the math explanation at the beginning just continue reading as you don’t need to have a degree in math and science to understand what’s going on.
This morning I was greeted with a blog post from the fine folks over at Qualys on how BEAST isn’t really still a threat (unless you are using an Apple product). BEAST, a vulnerability found in SSL and TLS 1.0, was discovered around this time a couple of years ago and put web users in a precarious position of using a poor cipher choice (RC4) or be vulnerable. Not to worry, however, as developers were able to come up with a solution to the problem (n/n-1).
So I mentioned the Qualys article in my $dayjob IRC channel where my always awake coworker provided information that Fedora is, in fact, still vulnerable to the attack. Thanks to a problem with pidgin-sipe connecting to a Microsoft server, the n/n-1 split was backed out of the NSS software leaving anything that depends on it potentially vulnerable (Chrome, Firefox, and Thunderbird to name a few).
There is a fix, although it’s not fantastic by any stretch of the imagination. By simply adding these two lines to your /usr/bin/firefox file the vulnerability should be fixed:
We added these two lines at line 36 and restarted Firefox. My way-too-awake coworker did a test and confirmed that it was working in his environment. Your mileage may vary.
Hopefully the fix for BEAST can be reapplied to NSS in Fedora soon as leaving users exposed can be dangerous.
Thanks to Hubert Kario for pointing me, and walking me, though this stuff before my morning coffee.
Update: 2013-09-12 @ 14:30 UTC
Apparently this problem will be persistent according to the NSS package maintainer. From the ticket:
I bit of information from the nss side of things. The nss disabling patch is not applied on Rawhide or f20, onlt applied on stable branches. After we branch Rawhide for the next fedora release and we enter in Alpha, I send emails to the fedora development mailing list telling them that NSS_SSL_CBC_RANDOM_IV=1 will be the default as they use updates-testing and ask for feedback on whether it causes problems. Twice they have said it still causes problems. There are still unpatches servers out there. Once we go beta I have to enable the patch again. f20 is entering Alpha soon so I’ll send that email again. I know this bug is for Firefox but I though worth informing you that we monitor this every six months for nss.
Update: 2013-10-10 @ 15:22 UTC
Update: 2013-10-17 @ 10:32 UTC
I believe this problem has been fixed (finally!) for Fedora 19 and beyond.