TylerBurton.ca

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.

In cryptography a key length refers to the digital size of the ‘key’ used to unlock the encryption algorithm. Over time the length of these keys has increased from DES’ modest 64 bit (really 56 bit) key size all the way to the new AES specified key lengths of 128 and 256 bit keys. Each bit increase in in the algorithm doubles the potential number of keys available to use, thus usually making it harder for an adversary to guess the right key.

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.