Archive

Archive for the ‘GnuPG’ Category

Poll Results: Do you use OpenPGP or GnuPG?

2013-03-07 2 comments

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.

Categories: GnuPG, OpenPGP, Poll

Hashing Algorithm: Is your GPG configuration secure?

2013-02-21 2 comments

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.

My web of trust

2013-01-26 Leave a comment
Web of Trust built on 26 Jan 2013

Web of Trust – 26 Jan 2013

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.

Categories: GnuPG, OpenPGP Tags: ,

New year, updated keys.

2012-01-03 Leave a comment

GnuPG LogoI 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:

Daily Histogram

Time New Keys Updated Keys
2012-01-02 266 210
2012-01-01 251 6422
2011-12-31 191 99
2011-12-30 287 133
2011-12-29 326 112
2011-12-28 297 154
2011-12-27 290 133
2011-12-26 248 84
2011-12-25 146 55
2011-12-24 157 81
2011-12-23 216 99
2011-12-22 330 152
2011-12-21 326 146

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.

Categories: GnuPG Tags:

FUDCon Blacksburg PGP Key Signing Event

2011-12-19 Leave a comment

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.

Also, Nick (nb) is planning a CAcert Assurance event as well (probably will co-exist with the PGP key signing).

Hope to see everyone there!

Fedora Web of Trust keysigning at FUDcon Pune

2011-11-01 Leave a comment

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!

Poll: Do you use PGP or GnuPG?

2011-10-13 Leave a comment
Categories: GnuPG, Poll, Privacy, Security

GeekNote: PGP/GnuPG Key Statistics Tools

2011-10-02 Leave a comment
Categories: Encryption, GnuPG

Protecting your email from disclosure

2009-12-07 Leave a comment
Climate talk, Alaska government business, and Dave Briggs.  What do these three things have in common?  Each of these subjects had more light shown on them by someone crackingemail messages and releasing those messages to the public over the Internet.  Of course there are many more of these events that happen on a daily basis but those three were the bigger ones that I could think of right off hand.So, the bigger question than why did I choose those three examples is how do we prevent such disclosures in the first place.  The answer is actually simpler than you might think.So let’s break this down into a couple of different categories.  We’ll start with authenticating a user into their email messages, go to protecting your message while it’s enroute, and end with protecting the message while it’s being stored.

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.

Follow

Get every new post delivered to your Inbox.

Join 167 other followers