I spent the week at the Fast Software Encryption and AES-3 conferences in New York. The big news is that there was no big news. All five candidates still look solid, and there were at least as many papers on performance as on cryptanalytic results. Not only that, the former were more enlightening -- what can one conclude from a result (I won't call it an attack) that requires 2^229 partial encryptions, 2^69 bytes of memory, and 2^69 chosen plaintexts -- all to deal with a significantly-weakened version of a cipher? (Let me be fair -- the authors recognize that that isn't even a certificational attack. At most, they say, it may pave the way for future work that is more substantive.) There were several conclusions from the performance studies. First, RC6 and and MARS are by far the worst at key agility. This may be a serious concern for hardware implementations in some circumstances, especially for VPN gateways. (I spoke briefly at the rump session of AES-3 on why IPsec was a very demanding a situation for key agility.) A fair number of people seemed to feel that key agility is a major performance issue, as opposed to just bulk encryption. When looking at hardware implementations, Serpent did very well. This is in marked contrast to its well-deserved reputation for being slow in software. My own view, not necessarily shared, is that all of the algorithms can do at least 10 Mbps on modern CPUs in software without breaking a sweat, and that above that one is likely to be using hardware regardless. There was fairly strong opposition to the idea of picking two "standards". That said, the notion of a primary and a backup algorithm did seem to have broad support. Note that the criteria for a primary/backup pair versus an AES1/AES2 pair are different -- for the latter, I'd be more inclined to pick two choices with different performance niches, while for the former I'd pick an extremely conservative cipher for the backup. My rationale is that they all look very strong today, which means that a real crack would be likely only from major new cryptanalytic results. Such a result would be likely to affect all of the candidates; thus, one would want a backup with a high margin of safety. Besides, by the time one had to switch, Moore's Law would have dealt with many of the performance issues. Which will be the eventual winner? Rijndael still looks like a very strong contender. It's very fast in hardware and software, and (from the comments during the panel session this afternoon) was the second choice of most of the submitters, if their own algorithm were not chosen. Some people feel that Rijndael should use more rounds, out of conservatism; fortunately, its structure is amenable to that. Each of the finalists submitted a summary statement; these should be on the NIST web site (www.nist.gov/aes) shortly. These are worth reading, since they provide a capsule summary of the strengths of each algorithm, plus (in some cases) refutations of the major criticisms leveled against them.
