1. For Frog, encryption and decryption speeds are different on Pentium (2600 and 1980, resp).
  2. For DFC, I rely on the personal communication with Serge Vaudenay. The documentation outlines ANSI-C and Extended C. I use the later numbers. Also, for 6805 implementation I've included the 200B version (the 100B version takes 200,000 cycles). The implementations by Rob Harley for AXP 21164 are in C but use opcode macros. (it's questionable wether it should belong to the row of C or the one of asm)
  3. For Rijndael, the encryption speed depends on the key length. I've included the 128 bit key version.
  4. For Twofish, several tradeoffs of speed, complexity and memory are possible. In this table I've included the fastest versions.
  5. For Crypton, the 390 cycles/block implementation is written in C with inline asm.
  6. SAFER+'s document does not specify the compiler used (page 25: "ANSI C implementation"), the correct compiler was MSC++ 5.0. Thanks to Jim Foti and Lily Chen for clarification. Also, Safer+ has different number of rounds for 128 bit key (8r), 192 bit key (12r) and 256 bit key (16r). Here I mention only the speed in the case of 128 bit key - it's still slow.

    Rieks Joosten (private communication) has estimated the hardware implementation speed in a .35 micron technology, based on an actual Safer implementation.

  7. Brian Gladman is as far as I know, the only person who has implemented all 15 candidates. His page has an excellent explanation of how he measured the times. His implementations of two early broken ciphers (2168 cycles per LOKI and 6549 cycles per Magenta) are not included into crosstable.
  8. Brian (personal communication) on his Pentium implementations:
    I have used the compiler optimisation switches for the Pentium rather than the Pentium Pro but the source code itself has been optimised for the latter so the results are a long way below what is possible on the Pentium with proper optimisation for this processor.
    Note that those numbers were measured by using his early variants of code.
  9. There is a separate row for Lous Granboulan's timings on AXP 21164, using DEC C and gcc 2.8.1. He used Brian Gladman's original (but not the final) code and recompiled it on Alpha (therefore some of the timings may be far from optimal, esp DFC and HPC).
  10. Regarding the Merced/McKinley estimations, here's a quote from Doug Whiting's mail:
    You can put the Merced/McKinley numbers up, but please add some caveats to them, as follows. The Merced/McKinley ratios versus Pentium II are still preliminary -- it's possible that there will be some changes in them, although we believe that they are reasonbly close. Thus, most ratios intentionally have only one significant digit, with a few minuses indicating that the rounding was "close".

    We have simulated the RC6 code fully and know that its "slow" numbers are for real. We will finish simulating the assembly code for the other algorithms in the near future.[...]

    Here are the latest results, with an average of encryption and decryption times used for the ratios (Serpent and RC6 are slightly asymmetric):

    	          P2   PA-RISC Merced/P2 McKinley/P2
    	RC6       250  547     2.5       2.1
    	Rijndael  283  186     0.6       0.5-
    	Serpent   900  610     0.8       0.8
    	Twofish   258  222     0.9-      0.7