Just for a brief cryptography break (:-) I'm forwarding
Steve Bellovin's comments from the AES-3 conference.
>From: Steve Bellovin <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: nothing major at AES-3...
>Date: Fri, 14 Apr 2000 21:29:48 -0400
>
>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.
>
>
>
Thanks!
Bill
Bill Stewart, [EMAIL PROTECTED]
PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639
