# Why Camellia paper declares that it is faster than Rijndael while it is actually much slower?

I'm writing an assignment on Camellia cipher, reading the [NTT paper][1] they declare a speed at least comparable with Rijndael, but, searching around, I found that it is actually much slower [2]. I thought this may be caused by AES using specific cpu subsets, but even without them it is faster than Camellia with them [3].

• [2] doesn't even state which mode of operation they used. Feb 14 '18 at 12:18
• it is possible that in an implementation with side channel resistance, the slowdown on AES is more, i am not sure Feb 15 '18 at 1:25

The paper says it is comparable in speed hardware and software to the AES finalists.

If we look at low end hardware performance, say cycles and resource bytes on a Z80 smart card:

Cipher         Keysched  Encrypt  RAM-KS RAM-ENC ROM-Total
----------------------------------------------------------
AES            10318     25494    32     34      980
Camellia       5146      28382    44     62      1698
Twofish        28512     31877    56     34      2808
RC6            138851    34736    90     124     1060
MARS           21742     45588    512    60      5468
Serpent        147972    71924    96     68      3937


AES is the fastest, but only about 11% faster than Camellia, all the other finalists are slower. Resource usage is also good, I would say their claim of being comparable is accurate, if not understated.

If we look at modern CPUs with hardware acceleration, what you saw was that AES is about 4 times faster. Without the hardware acceleration, Camellia is 2/3 of the speed of AES, slightly faster than Twofish, and faster than Serpent. I would say the claim still holds here, just not as strongly against AES.

For FPGA hardware from the Camellia paper in 2001, AES was clocked at 1540Mb/s using 1857 slices, whereas Camellia was clocked at 6750Mb/s using 9692 slices. Comparing rate/slice, they are within 20%. On other FPGA and AES with higher gate counts, AES will have a strong advantage, the Amphion CS5240X2 core on Xilinx Virtex2 clocks at 10Gb/s using only 2200 slices... and AES on Virtex4 clocks at 17.9Gb/s using 18400 slices, very very fast. AES is most likely more efficient on Virtex5, it can perform at 4Gb/s using only 350 slices, which 12 times the rate/slice of Virtex4. Camellia on Virtex5 using 132 slices operates at 85.4Mb/s, much slower. On a Spartan-3, AES does 2640Mb/s using 390 slices, and Camellia does 33Mb/s using 321 slices and half the clock speed.. or roughly 1/40th the rate per clock.

For ASIC, unrolled (1 cycle) on a 180nm process, Camellia performs at 25MHz using 355K gates, and an Amphion CS5240TK AES chip performs at 200MHz using 203K gates, a big difference, and a win for AES at 8 times the speed.

The closest looped ASIC frequency/area match is a 172Mhz 21 cycle Camellia implementation running at 1051Mb/s using 11.87K gates, vs the Amphion CS5220TK 200MHz 44 cycle processor at 581Mb/s using 14.8K gates, I call that one a win for Camellia since the speed per gate is more than double.

In the proposed Cryptoraptor configurable cryptographic processor, Camellia and Twofish run at half the speed of AES.

Considering that Camellia is a more complex cipher with more rounds, I consider their generalized claim of "comparable" to the finalists to be accurate, the AES winner Rijndael on the other hand does have an advantage due to its simplicity and low resource usage, based solely on the round count you would expect it to be 60% faster than Camellia in software table lookup, which it is. You can generally expect AES to be at least twice as fast in high end hardware, and about the same speed in low end hardware.