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:
- Security
- Interoperability
- Performance
- 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.
