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.

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).

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!

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.

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!

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

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.

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

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

A common question people come up against is what key size should I use? Luckily I found a website the other day that explores just this. It takes recommendations from the world’s foremost crypto experts and from cryptography conferences to present an estimation of an appropriate key length to use. What’s more they even compare symmetric key lengths, like AES, to asymmetric key lengths, like public key cryptography such as RSA, so you could see just how large of a key size you need to achieve relative security.

For simplicity I have included below the recommendations from various sources released in 2009. All of them are for the highest level of security suggested, so that might be a little overkill for every day use.

Note: The asymmetric numbers listed here are to show how large an asymmetric key should be to get equivalent security to a symmetric key. However this is not how most asymmetric keys are used. Instead they are used just to encrypt a symmetric key which does all of the work, the so called hybrid approach, because symmetric algorithms are much, much faster. As such most of these sources also make it a point to mention that an El Gamal or RSA key should actually be about 2048+ bit in size for a decent trade-off.

As you can see even among the experts the numbers vary quite a bit. To me this just proves that no one really knows how much security you need. The best you can do is decide on a decent trade-off between security and performance for your purposes. Nevertheless it is still interesting to see what the experts have to say when it comes to choosing a key length.

For the record, the suggestions I will be making in these tips are simply things that I have found to work for me. Whether or not they work for you, or even are appropriate for you, falls completely upon you to decide.

Note: I understand that JavaScript can be useful for many things, for example as a PDF form auto-competition mechanism. That being said I have never needed this feature and since disabling it many months ago I have never had to enable it for a single PDF. While your circumstances may vary from mine, I still do not see any harm in disabling this feature and then only selectively enabling it when and if you ever need it.

Adobe Acrobat Reader

1. Open Acrobat Reader
2. Open the Preferences window. To do this click Edit > Preferences
3. Click JavaScript on the left
   
4. Uncheck “Enable Acrobat JavaScript”
   
5. Click OK
6. You’re done!

Foxit Reader

1. Open Foxit Reader
2. Open the Preferences window. To do this click Tools > Preferences
3. Click JavaScript on the left
   
4. Uncheck “Enable JavaScript Actions”
   
5. Click OK
6. You’re done!