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!
Swiss OpenPGP Keyserver (where PGP Pathfinder obtains its data)
Sparks’ Linux Journal by Eric “Sparks” Christensen is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Permissions beyond the scope of this license may be available at https://sparkslinux.wordpress.com/license/.
So, if our email providers would provide its users with better ways of authenticating then many of these problems will go away. Multi-factor authentication is an absolute must! Something you know (a password), something you have (a token), and something you are (biometrics) make up multi-factor authentication. When you hear two-factor authentication they are talking about using two of those to authenticate you into the system which makes guessing your password much more difficult.
A good example of a company that gets it would be Paypal. They provide an option to use VeriSign Identity Protection in addition to a username and password. This is an excellent example of two-factor authentication in action. A good example of a company that doesn’t get it would be AOL. They allowed their customers to use RSA SecurID tokens to provide that second authentication factor but recently have decided to stop the use. Apparently they feel that their customers are too stupid to push a button, see a number, and type it into a computer. Bottom line is you should take your business to someone who takes authentication security seriously.
For those who use passwords (and we all do) make sure you use passwords that don’t include words that are in the dictionary, family or friend names, or things that other people could guess. Dictionary attacks against passwords are common because they work! Oh, and your favorite football/baseball/hockey/whatever team’s name is in the dictionary used to crack passwords… trust me. And the longer the password the better. You can exponentially increase the strength of your password by using twelve characters instead of eight, but don’t let that make you stop at twelve characters.
Okay, so we are using strong passwords and we have a token… that’s all I need, right? Not quite. What would you think if I told you that your message can be read at any point along the route to its destination? I’ve always been told that sending an e-mail is like sending a postcard but it’s actually worse. Imagine sending your message on a postcard and then handing it to someone else for delivery. Do you trust that unknown someone who is going to deliver your message? Well, e-mail is exactly the same way. So what can you do? Easy… use encryption!
Oh, I know you don’t think you know anything about encryption and the mathematics that goes along with it but it’s really easy! There are basically two different styles of e-mail encryption: S/MIME and GPG (or PGP). While S/MIME is more hands off, it costs money to get a certificate from a Certificate Authority and then you are basically trusting their trust model taking you out of the trust equation. I’m not impressed. GPG, which is the open source implementation of PGP, is my choice.
I’m not going to get into how to setup GPG because their are lots of instructions already out there. I have helped with documenting how to setup GPG in a number of email programs and even for Gmail, though, and will say it’s in the Fedora wiki.
Anyway, what makes GPG my choice is that not only is it easy to use but it is also completely free. You generate your own keys and can upload your public key to one of the public key servers (like MIT’s key server) which makes your public key available to all. This doesn’t make your encryption vulnerable because this is public-key cryptography and not symmetric cryptography.
So by using GPG (or S/MIME or PGP) you are protecting your message enroute to its destination. So now we have to protect the message now that it has arrived and is being stored on someone else’s server. The great thing is that because you encrypted before transmitting it can only be decrypted by the recipient so it should be left unreadable to anyone cracking into your email account. So if the cracker does get into your mail account then all they will find is scrambled up characters that they won’t be able to understand.
So by using multi-factor authentication and encryption you can remove most risks of using e-mail and keep your information yours. Think you don’t need to protect your information because no one would want to see what you write? Think about the three subjects we started with and remember those are just some of the more recent, public examples. It happens every day.