3
$\begingroup$

Which parameters should be used to compare AES vs Camellia? Their runtime ? The size of the encrypted data output?

$\endgroup$
  • 4
    $\begingroup$ That depends on what you want to use it for. In general you should go for AES unless you're required to use Camellia. The differences will be minimal and AES is used much more often, has better support and is more likely to be implemented / accelerated. $\endgroup$ – Maarten Bodewes Nov 7 '17 at 12:36
  • $\begingroup$ @MaartenBodewes Well, I should have clarified that, but my sole goal here is to compare then both. $\endgroup$ – alvaro vidal Nov 7 '17 at 13:14
5
$\begingroup$

Both AES and Camellia are block ciphers with a block size of 128 bits and three different key sizes: 128, 192 and 256 bits.

In both cases, when using a bigger key size, like 192 or 256, the cipher will do additional rounds. AES will do respectively 10, 12 and 14 rounds for 128 bits keys, 192 and 256, while Camellia do 18 rounds for 128 bits keys and 24 rounds for both 192 and 256 bits keys.

So far so good, all this information can be found on Wikipedia.
So, you want to compare both, but what kind of metrics do you want to use?
What are the key performance indicators you're valuating most? Is it the raw speed? Is it the security against differential power analysis? Is it the parallelization of the computation? Is it the number of line of code in an implementation? Is it the maximal code footprint? Is it the resistance against algebraic attacks?

I'll do the assumption that what you really want to do is comparing "implementations" of both ciphers, not the underlying algorithms (there certainly are papers doing so for both ciphers).

In order to compare implementations, you have two options:

  • Either you take reference implementations, without much optimization and compare then
  • or you take the "best" implementations out there and compare them.

As stated by Maarten in comments, AES being the most used block cipher nowadays, the currently best implementations all rely on the fact that there are hardware accelerators for them in almost all processors. However, it appears that Camellia can also be accelerated using some of the same tricks as AES [1]. I recommend you to take a look at this thesis, since the author is comparing different block ciphers, including both AES and Camellia, and tries to optimize their raw speed. According to its results, Camellia is still 4 time slower than AES, even using the AES-NI tricks.

Now that last paragraph takes into account only the "raw speed" of the implementations, but an implementation can also be hardened against certain kind of attacks depending on the threat model scenario it tries to address. For instance, bit-sliced DES introduced by [2] is faster than standard DES (and is constant time), but there might be other hardening methods which are not necessarily improving the performance, like for instance the "infective countermeasures for RSA" against fault attacks, which add an overhead, or the "masking" used in RSA implementations meant to resist to DPA attacks.

In order to perform such comparisons between the "features" of the implementations, then you need to probably review the code and check what's being done. (Or have a list of the "features" the implementations sports.)

In the end you could also compare the usage of both ciphers, or the patents, or the amount of paper written about both, etc.

Notice that you can also look for existing benchmarks out there, if you what you care about is the speed, like for example the ones done by Crypto++, or the ones found in the above-mentioned thesis.


References

[1] Kivilinna, Jussi. "Block Ciphers: Fast Implementations on x86-64 Architecture." MSc diss., University of Oulu, 2013.
[2] Biham, Eli. "A fast new DES implementation in software." In FSE, vol. 1267, pp. 260-272. 1997.

| improve this answer | |
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.