Say you are travelling, or are at a neighbourhood coffee shop, using whatever unsecured WiFi network they make available. You could either:

1. trust that no one is sniffing your web traffic, capturing passwords, e-mails, IMs, etc.
2. trust that no one is using more sophisticated methods to trick you into thinking that you are secure (i.e. man in the middle attack)
3. route your Internet traffic through a secure tunnel to your home PC before going out onto the web, protecting you from everyone at your current location

which would you choose?

VPNs and SSH tunnels are actually a relatively easy means for you to be more secure while browsing the Internet from potentially dangerous locations. There are many, many different ways for you to do this but I find using a Linux PC that is running on your home network to be the easiest.

1. Configure your home Linux PC. Install ssh (and sshd if it is separate). If you are using Ubuntu this is as easy as running the following command: sudo apt-get install ssh
2. Sign up for a free DNS service like DynDNS so that you know of a web address that always points to your home Internet connection. To do this follow the instructions at the service you choose.
3. On your laptop (that you have taken with you to the hotel or coffee shop) connect to your home PC’s ssh server. If you are on Windows you will need to get a program like PuTTY. See their documentation on how to forward ports. On Linux you can simply use the ssh command. The goal is to forward a dynamic port to the remote ssh server. For instance if you are using a Linux laptop and ssh then the command would look something like: ssh -D [dynamic port] [user]@[home server] -p [external port number - if not 22]. An example of one would be ssh -D 4096 user@example.com -p 4000
   
4. In your browser open the networking options window. This will allow you to tell the browser to forward all of its traffic to a proxy, which in this case, will be our dynamic port that we set up in step 3. Here is an example of my configuration for the example above.
5. Browse normally.

You are now browsing the Internet by routing all of your traffic (in Firefox) securely through your home PC. Note that this doesn’t actually make web browsing any more secure beyond protecting you from people in your immediate vicinity (i.e. connected to the same insecure WiFi network).

I logged onto my desktop the other day, for the first time in a couple of weeks – I’ve been away travelling, and was surprised to notice that my PGP key was set to expire. Long story short I have generated a brand new key.

OpenPGP Key

Name: Tyler Burton
Key ID: 0x1CD3E3D8
Key Fingerprint: 96ED 6B13 10B1 69C1 8299 693C 2921 6D80 1CD3 E3D8
Keyserver: pgp.mit.edu
Key Algorithm: RSA
Preferred Cipher: AES256
Preferred Digest: SHA512
Direct Download: Download Here

Canada still imposes restrictions on encryption. Who knew?

Today I happen to read something that Michael Geist had written about Canada’s state of encryption laws and I was floored. In it he referenced this article which discussed the Government of Canada’s new public consultation on encryption laws. From the article:

Encryption controls have been a challenge for many Canadian software and hardware vendors. Category 5 — Part 2 of Canada’s Export Control List identifies information security items that require a permit in order to be exported from Canada to destinations other than the United States. Because the threshold for control is very low — key lengths in excess of 64 bits (in the case of symmetric algorithms) — many vendors have been surprised to learn that the export or transfer of their encryption goods and technology requires a permit before shipment to their foreign customers. Often, they first discover this when the Canada Border Services Agency detains these goods just prior to export. Failure to obtain a permit prior to exporting or transferring controlled goods or technology can attract significant penalties.

The reason I am so surprised by this is that today, in 2010, 64-bits is nothing. For a recent school project a few colleagues of mine and myself designed a distributed brute-force approach to cracking an RC4 key. Doing some internal algorithm speed tests we determined that a single machine could brute force approximately 402,000 different keys per second. At that rate it would take one machine 1,455,081 years to check all 2^64 keys. Seems pretty good so far huh? Well the problem with this number is that we are not professional cryptographers. RC4 has known weaknesses that allow you to break it faster than a brute force attack would otherwise allow. But assuming you still attempted to complete the brute force method, I highly doubt it would take that long. DES, the older, widely used, encryption standard, also had a key size of 64-bits but, thanks to specially designed hardware, is now able to be broken in less than a week. While it is true that not all algorithms are built equally (i.e. AES with a 128-bit key is more secure than RC4 with the same sized key) it is generally true that having a larger key size and a secure algorithm are good things. According to current Canadian encryption laws 64-bits is deemed to be the strongest security you can legally export without a permit. Clearly this current limitation is simply unacceptable.

When you visit a secure website, for example your bank’s, your browser usually uses a 128-bit or 256-bit secret key to ensure that absolutely no one can listen in. And yet this security, the very security that gives people piece of mind when they shop online, is essentially illegal to export or sell overseas with our current laws. I completely agree with the author of the article when he says that requiring Canadian businesses to secure a permit before they can ship their software puts them at a distinct disadvantage.

Additionally, the Canadian government has allowed themselves to fall behind the security curve in other ways. Recently a good friend of mine was hired for a research job at the Government. In order to move him through the hiring process they requested that he send sensitive materials like his SIN and birth certificate through unencrypted e-mail to them. And you wonder why identity theft is so bad…

We as citizens and workers have some real things to gain or lose depending on the outcome of this consultation. If the current law is allowed to stand we will be stuck at a competitive disadvantage and have to choose between either less security in exported software products or more paperwork.

So do your part and make sure Canada doesn’t get stuck behind the technology curve. Join the debate.

I have been meaning to write up a short post about this for a while, but thanks to the start of a new school term I have been a bit busy.

If you have seen the security news in the last month or so you will know that RSA-768, a 768bit or 232 decimal digit asymmetric key, has been broken (factored). This has important security repercussions for all of us because it is these public key algorithms like RSA, or ElGamal, that guard our online transactions, and e-mail conversations.

So just how much should we be worrying about this newest ‘break’?

When it comes to public key cryptography it is important to remember that their security is essentially in our inability to factor them quickly. The only real way that public key cryptography could be considered broken is if we find a way to drastically increase our ability to factor massive prime numbers. Thankfully that time is still far away. In fact after digging into the news articles a little more it quickly became obvious that the feat of factoring a 768bit key, while incredibly difficult, was inevitable.

So what now?

Nothing. Currently the most popular asymmetric key size in use is 1024bit, which represents a work load increase of over 1000 times when compared to RSA-768. Still afraid? Check out the list of RSA challenges that have been issued over the years and just how few have actually be ‘broken’.

In choosing my current PGP/GPG public key I decided to go with a 2048bit one, which, according to all accounts, will be safe for years to come. As always, I recommend checking out this site for the most up to date key length recommendations from the world’s foremost cryptography experts.

There you have it

With the knowledge that you’re online transactions are still perfectly safe you have nothing to worry about.

For reference, the currently recommended key lengths for asymmetric encryption algorithms, like RSA, are 1976bit (BSI recommendation for use after 2016), 2048bit (NSA recommendation for current and future use), and 2432 (ECRYPT II recommendation for protection until at least 2030).

Well GPG to be more accurate

As my existing key was set to expire at the end of this year I have issued myself a brand new one! After much though I finally decided that creating a new key from scratch was the best idea, rather than simply adding a new subkey, because I wanted to move away from DSA/ElGamal toward RSA primarily because of the weakening of SHA1. If this all sounds like gibberish to you then don’t worry, the details aren’t nearly as important as the security provided by my new key.

If you’d like to make use of my new key please head over to the About Me section where you will find it!

That’s right an update to your favourite hash verification program!

This update includes a few new features that some of you might find useful. It also includes help documentation which walks you through how to use it!

New Features

• Menu strip for even easier use
• Export features allows you to automatically write all of the hashes to a single file
• About dialog that provides information about the program
• Help documentation

Requirements:

• All platforms: .NET 2.0+ / Mono, a graphical display
• *nix platforms: WinForms (identified as System.Windows.Forms)

As always the binary only package contains just the executable, whereas the all package contains the source code as well.

Well its almost time for me to create a new PGP key. My current key for tyler at tylerburton dot ca is set to expire at the end of the year and I am trying to determine what the best way to migrate to a new key is. Some people suggest simply adding a new encryption sub key and then changing the original signing key’s expiry date so that individuals wishing to verify your signatures can continue to do so uninterrupted. Unfortunately my current key is an ElGamal/DSS based one and, after the recent increased attacks on SHA1, I would really prefer to move to an RSA based key.

Alas I think I’m going to have to just create a new key and sign it with the current one. If anyone has any better alternatives please let me know!

Public key cryptography is one of the most essential pieces to online security. It is at the root of what enables you to shop online, do secure online banking, and communicate securely. I will be focusing on the latter in this tip. But first a quick and simple refresher on what public key cryptography is and how it works.

How public key cryptography works

Or rather how you use it. Cryptography allows you can lock any data or information inside of a digital safe. Generally this is done through the use of a shared key (password). This is similar to how you, and only you, can log on to your home wireless internet. But what if you don’t already have a shared key? This is where public key cryptography comes in to play.

Public key crypto works by using two keys instead of one. We will call these keys the public key and the private key. The public key can be thought of as your listing in a phone book, you want everyone to be able to get a hold of it in case they need to get a hold of you. The private key on the other hand is like your voice mail password, you only want one person to know it: you.

Messages and data encrypted with your public key are put into a digital safe that can’t be opened by anyone, even the person who just put the data into the safe, except you. This is important because it means anyone and everyone can encrypt things to send to you but you will be the only one able to decrypt them, or open the safe.

OK, so I can encrypt things with your public key and only you can open it. Now what?

Now we use it to send private e-mail.

Pretty Good Privacy (PGP)

PGP uses a system of keys which are actually just public and private keys. If I want to send you a private e-mail I just need to get a hold of your public key. For added integrity I could also sign the message using my private key, which you could then in turn verify with my public key, but that is beyond the scope of this post. Set up correctly not only does PGP allow me to receive secure e-mails, that no one but me can read, but also verify that the person who actually sent me the e-mail is who I think it is.

GNU Privacy Guard (GnuPG)

GnuPG is a a free and open source implementation of OpenPGP that is very common. Most Linux distributions come equipped with it by default but Windows users will most likely need to download it. Several e-mail clients also integrate seamlessly with GnuPG which makes things very easy. Others, like Outlook and Thunderbird, simply require an add-on.

How to get GnuPG

This is a simple step but is crucial to getting everything to work. Jump over to the official website, http://www.gnupg.org/, or hop right over to their download section here and grab a copy of it. For Window’s users you can just grab the binary, indicated by the letter B, while Linux and Mac users should either look in their software repositories or follow the links available. Once installed GnuPG, or gpg as it will be called, should be good to go.

Generate your first key

There are a number of different ways to generate your keys, from within the terminal or command line to within your favourite e-mail client. Rather than cover all of the numerous possible ways that you could generate your key I’m going to only cover two: the terminal and from within Thunderbird (see below).

1. Open up a terminal or a command prompt

2. Type:

gpg –gen-key

That’s two dashes before “gen”

3. This should prompt you with the following options:

Please select what kind of key you want:
(1) DSA and Elgamal (default)
(2) DSA (sign only)
(5) RSA (sign only)
Your selection?

As you can see there are a couple of different options. Let’s break it down a little. Digital Signature Algorithm, is the standard way of signing messages. El Gamal is a widespread way of encrypting a message. Finally RSA is a versatile algorithm that can do both (don’t worry about the sign only part of #5, we can fix that later).

For your first key I recommend making a test key just so you can familiarize yourself with the steps required.

4. Type the number “1″ and press Enter. It should now be asking you what size you want the key to be.

DSA keypair will have 1024 bits.
ELG-E keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048)

The current recommendations seem to be that a 2048 bit key is a very good idea. Creating a larger key will make it more secure but might take a bit longer to generate the key. For now let’s just go with the default 2048. Press enter.

5. Next gpg will ask you how long the key should be valid for. This expiry date is important because should you lose your key, or have it compromised, you will at least feel good that eventually it will become invalid. For this example key we will set it to expire tomorrow. In order to do so type “1″ and press enter. If you wanted it to expire in one week, month, or even year you just need to instead type “1w”, “1m”, or “1y” respectively.

Please specify how long the key should be valid.
0 = key does not expire
<n>  = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0)

6. This is where you would enter your personal information. You don’t want to lie about this because this key is meant to identify you as you and only you! However for this example I am going to enter the following information:

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) <heinrichh@duesseldorf.de>”

Real name: Test Key
Email address: testkey@tylerburton.ca
Comment:
You selected this USER-ID:
“Test Key <testkey@tylerburton.ca>”

Once you have verified this information type “o” and hit enter for “OK”

7. It will now prompt you for a passphrase. A passphrase gives your key some additional security. Once your key is generated you want to make sure that no one else can get a hold of your private key. If someone does don’t panic, there are ways for you to revoke the key, but a lot of damage can still be done with someone reading your encrypted e-mails or impersonating you. A passphrase makes it difficult for someone to decrypt your e-mail or impersonate you even if they have a copy of your secret key.

8. One you finish this GnuPG will generate the large prime numbers used in your key. This may take a while depending on the hardware you are running. When it’s done you will be shown your key’s information. It should look something like this:

pub   1024D/E1775F9E 2009-10-04 [expires: 2009-10-05]
Key fingerprint = 6DD1 5B41 1279 03E5 1088  225C 5B1B 90A9 E177 5F9E
uid                  Test Key <testkey@tylerburton.ca>
sub   2048g/4DDF6291 2009-10-04 [expires: 2009-10-05]

9. That’s it! You now have a key that you can use to securely encrypt your e-mail and files. Just be sure to get your public key out to as many people as possible. You can even upload it to a public key server so others can easily retrieve it.

Setting up Thunderbird

Obviously these instructions will only work if you use Thunderbird as your mail client. That being said a quick google search provide you with all of the answers you’ll need to set up PGP with your e-mail client of choice.

1. Download and install the Enigmail add-on for Thunderbird.

2. This will add a title bar option labeled “OpenPGP.” You may want to turn on expert mode to give yourself some extra options but that’s your choice. Inside of this menu you will find something called “Key Management.” If you click this, it will show you all of the keys you have stored in your key ring. The ones for which you have a private key are highlighted in bold.

3. Next go into your account settings and you’ll notice a new option called “OpenPGP Security.” Click this and check the box called “Enable OpenPGP support.” This will add two small icons to the bottom of your new e-mail composition window. One looks like a pen and when it is highlighted means you will sign the e-mail, proving that you were the one who sent it. The other is a key; if you have the recipient’s public key you can use this to encrypt the message you are sending so that no one else will be able to read it. Take a look at the options provided and set it up to your liking.

4. That’s it! You now have PGP support for your e-mail! If you feel like creating a new key, or even your first key, I would suggest doing so from the Key Manager inside of Enigmail instead of via the command line. It provides a very easy wizard to walk you through.

Final points

1. Hopefully this mini-guide  hasn’t scared you away from trying PGP yourself. If you are asking yourself ‘why should I even bother? I have nothing to hide’ you should take a moment while sending that next e-mail and consider if you instead wrote the same thing on a postcard and sent it on an around the world trip. This analogy gives you an idea of how little privacy your current e-mails have. As they are sent out over the internet they hop from server to server until they reach their destination. You have little to no control over what these servers do with your e-mail. Still have nothing to hide? Then you are far less concerned about identity theft then I am.

2. I said above, when selecting what type of key to create, that if you chose RSA (sign only) you could still use it to encrypt e-mail. This is true and all you need to do is edit the key by typing:

gpg –edit-key [e-mail address goes here]

(that’s two dashes in front of edit-key) and then on the next prompt entering:

addkey

This will walk you through adding an additional subkey, this time used for encryption. Just follow the steps as before and you should be set!

3. Remember PGP can be used for more things than just e-mail. You can also digitally sign documents and files or even encrypt them just like you can with your e-mail.

4. Now that you have this set up I fully expect any e-mail being sent my way to make use of it

In the world of computers interoperability is key. If I send you an e-mail from my machine I should hope that you’re e-mail client would be able to read it. This is why we have standards. Standards are a good thing. They allow people to focus on improving performance and driving down costs instead of splintering user base and polluting the world with… less than elegant designs.

But what if relying on a single standard is not the correct way to do things either? As someone who enjoys reading about computer security this is an area where I can see some strength to the argument that standards are both good and bad. Take AES as an example. If AES wasn’t the sole symmetric encryption standard we would run into a whole slew of interoperability problems… or would we? After all shouldn’t a degree of flexibility be a key piece of any good security system?

Now I know what you’re thinking. Why would we need to support more than one? Just look at these quick reasons why this would be an issue that I can name off of the top of my head:

1. Security
2. Interoperability
3. Performance
4. Cost

Security

Let’s first take a look at this. Think back to the Advanced Encryption Standard process that NIST was running which began in 1997. After many rounds of analysis NIST was presented with the choice of selecting a standard based on one of the following algorithms: Rijndael, Serpent, Twofish, RC6 and finally MARS. Any one of these could have ended up being what we call AES today. In fact the ‘winner,’ Rijndael, wasn’t even the most secure algorithm, just the best overall. With some of the recent attacks on AES perhaps it would have been better if a different algorithm was selected. Additionally, given the ability to use more than one algorithm opens up the possibility to use cascading ciphers, wrapping crucial data in more than one layer of security.

Interoperability

Interoperability is a huge issue when you are trying to make things work together. However rather than having a single interoperable cipher I feel as though it is much more important to have a single interoperable protocol. That way we could offer a variety of algorithms within it, so long as the protocol was flexible enough to be future-proofed. And don’t say we could never do this. The Transport Layer Security protocol which replaced SSL is perhaps the most widely used example of this, however many more also exist. All of these allow for multiple ciphers and algorithms to be used, thus allowing stronger ones to be added in the future. In fact a lot of these also allow the user to set just which algorithms they want to allow for security purposes; for example I don’t trust DES, so I won’t allow it.

But what if we don’t agree on a set of algorithms?

This is a good point, and really one of the only areas that this line of thought starts to break down. In general the existing protocols have solved this by requiring at least one algorithm, in each category, as a sort of fall back. Traditionally this has been DES and SHA1. Thankfully as time moves forward the protocols also develop and slowly change what these defaults are.

Performance

A real concern is algorithm performance. Some might think that by supporting more than one algorithm we run the risk of not improving the standard as fast as we could have been. However I think this concern is really overblown. In fact many of the other AES finalists have seen continued improvements since the end of that process.

Cost

Hardware cost is certainly an issue. The more features a piece of hardware supports, the more the hardware will cost. Not only that but supporting more than one algorithm in limited hardware just may not be feasible in certain circumstances, such as in smart cards for example. Still this is a scenario where the fallback algorithm could be used.

If AES just works, why bother thinking about the rest?

NIST was kind of unique in it’s decision to only support one symmetric block cipher. In fact both CRYPTREC and NESSIE, decided to select suites of algorithms. Unfortunately this means that NIST’s algorithm choices, which are in fact a subset of both CRYPTREC and NESSIE, are going to be the only ones really implemented – especially when the US is such a large market.

Conclusion

After everything is said and done I am more thankful that we have a strong common cipher available, rather than a lack of any. That being said I think choice and diversity is a good thing. I just wish more things would be designed with future innovations in mind rather than suddenly having to switch over when things go wrong.

I thought this little piece was amazing!

Moserware: A Stick Figure Guide to the Advanced Encryption Standard (AES)

Thanks for Bruce Schneier for spreading the news on this one.