0

I am running a comparison between lightweight ciphers versus non-lightweight.

My chosen lightweight cipher is Clefia which is a 128 bit block cipher by Sony and I am comparing it to the 128 bit infamous AES with both keys being 128 bit.

My comparison is being ran on a real mobile device running Android OS (Samsung Galaxy S3).

The paper about Clefia states that it is faster than AES.

This seems to be logical given it is a lightweight algorithm to be used on less resourceful devices.

In order to compile both code on android, I converted the official code of Clefia written in C to Java as is. (Although C could be compiled on android? not sure) and for the AES, I used the native Javax.Crypto libraries. (lots of examples on the internet for that)

What struck me is that the complete opposite happened. Instead of Clefia being way faster, it was AES which was around 350 times faster than Clefia.

The only reason now I can think of is that the code Clefia has posted on their official website is not optimized, which they admit; as the below is a copy-paste from their code.

* NOTICE * This reference code is written for a clear understanding of the CLEFIA * block cipher algorithm based on the specification of CLEFIA. * Therefore, this code does not include any optimizations for * high-speed or low-cost implementations or any countermeasures against * implementation attacks.

I can assume (I can be wrong) that the Javax.Crypto classes use much optimized version of AES.

This is the only reason I can think of why there would be such a huge difference regarding in speed.

Therefor my questions are as follows.

  • When we say optimized; what is meant technically? Less rounds in favor of security? different code? etc?
  • Can the reason for such a difference in speed be explained differently? that is, optimization not being the reason for such a difference in speed.
  • I still could not locate an optimized version of Clefia, and I am not sure if Java has included it with their latest JDK, given Clefia is now a standard. Is making an algorithm optimized left for the user that wants to use it to develop or the company (side that proposed the algorithm) offers?

Any ideas, insights and thoughts are highly appreciated. (In case you find a logical flaw in what I posted, please feel free to share. Also note that I was going to post this on http://crypto.stackexchange.com but the user base is way low there and this involves java, so at the time being I am posting it here, but if you think I need to move it there, please advise. Also, I do not mind sharing the code of both Clefia and AES if needed.)

tony9099
  • 4,567
  • 9
  • 44
  • 73

1 Answers1

1

Hardware Speed

In the paper you refer to, they show that Clefia when implemented in hardware, can be faster than AES when considering Kbps/gate. The best Clefia has 268.63 Kbps/gate and the best AES has 135.81 Kbps/gate - which is around a factor of 2.

Software Speed

They also have a comparison of software implementations where Clefia performs a bit slower at 12.9 cycles/byte than AES with only 10.6 cycles/byte.

So this shows that the speed of the two algorithms in itself are within a factor of 2.

Now, the problem is that you compare a highly optimized, and maybe even hardware backed (The ARMv8 instruction set now includes instructions that does a full AES round in one instruction) implementation, to your own java port of an implementation that is not optimized in the first place (The original code even states: this code does not include any optimizations for high-speed).

Also, how big is the data set are you testing on? And how is the effect of the JIT compilation been accounted for in the test?

If you want a comparative result, you ought to implement the AES algorithm in Java as well - and then do a comparison. My guess is that this approach would give an comparatively slow implementation of AES as well.

svlasov
  • 9,923
  • 2
  • 38
  • 39
Ebbe M. Pedersen
  • 7,250
  • 3
  • 27
  • 47
  • thats for the explanation. To be frank, thats what I did, did a bare bone class of AES with 128 bit key and compared apple to apple. The result was Clefia was much much faster. Although in software the factor was way high more than 2. The length of bits to encrypt were not big, and they varied between 272 for the shortest and 7560 bits for the longest. Also what do you mean by `the JIT compilation been accounted for in the test`? thnx – tony9099 May 03 '15 at 13:59
  • JIT Compilation = [Just In time Compilation](http://stackoverflow.com/questions/95635/what-does-a-just-in-time-jit-compiler-do). Java code is compiled to bytecode at compile time. At runtime this bytecode is then either interpreted or recompiled into native code, depending on where the hot-spots are in the code. If you run your encryption code many times, it will end up being compiled to native code that runs faster. If you only run it once it would be interpreted and would seem slow. – Ebbe M. Pedersen May 03 '15 at 15:03