Performance of Protocols

These are some thoughts I had based on the Advanced Encryption Standard contest that NIST has been running recently. NIST has been asking people to submit their ideas for crypto algorithms in an open evaluation process where everybody has a look at the algorithms and submits their comments. If this was a crypto conference I would be going into great detail on the internals of block ciphers. But this is not, this is a protocols conference and what we generally do is we try to take one step back. Rather than looking at the internals of what’s going on inside round functions, we start thinking about the application and what actually the block cipher is for. In the context of this AES contest, I think all the cryptographers have been looking at the wrong thing. Everybody’s been optimising block ciphers to shave small numbers of clock cycles off the time it takes to encrypt a block. OK, we are familiar with this. When I started doing work in this field in the mid 80s, the machine on my desk was a MicroVAX. It was connected to a dumb terminal, and it didn’t run the X windows system, firstly because Xwindows didn’t exist at that point, and even if it did the machine was too slow to run it. On this machine, doing encryption was a substantial proportion of the total amount of CPU the application used. And so consequently it was actually worth going to the trouble of hand assembly coding the block cipher to make it some tiny bit faster.