1

PREMISE:

I would to make analysis to see the encryption time difference between AES-128 ,192 and 256 version with Java. I checked that the three versions are built well (i had to change only the key 16 bytes for 128, 24 bytes for 192 and 32 for 256).

I saved the time before the encryption (and after the decryption) and i made the difference. For each payload i had a lot of values of time(nanoseconds)that i saved on a csv, so i made the average, because i wanted the "real" value. For example: For the payload of 7,8 MB i had 40 values of estimated time in a csv. I made the mean and i plotted the first point on MATLAB (7.8 , mean)...and so on for other values.

long startTime = System.nanoTime();
byte[] encrypt = ob.encrypt(tempBuffer, 0, read);
long estimatedTime = System.nanoTime() - startTime;

THE PROBLEM IS:

I plotted each value but i noticed that AES-256 is faster than AES-128 (and this is impossible). Someone said to me that the problem is the WARMUP effect of the JVM... how can i "clean" the JVM each time i run the program?

enter image description here

narraccino
  • 43
  • 9
  • 1
    Just the decline in time for ASE-256 from 15.6MB to 21.5MB indicates faulty measurements, encrypting more bytes must take more time. You ,might look at the SD for each payload/key size set of runs and look for outliers. – zaph Oct 22 '17 at 13:30
  • 3
    I suspect you are seeing the effect of hardware implemented AES support. On Linux type `cat /proc/crypto` or `cat proc/cpuinfo`. If any of these files contains the string `aesni` you have AES supported by hardware. Hardware implementations may be faster for `AES-256` than for `AES-128`. – blafasel Oct 22 '17 at 13:30
  • @the8472 i only want to know how to "clean" the JVM for having right data. – narraccino Oct 22 '17 at 15:42
  • for the purpose of obtaining a correct benchmark of the AES function? ... that is what the linked question covers – the8472 Oct 22 '17 at 15:50
  • 1
    Among other things: 1. Do not use the same file and/or same data between runs in-order to eliminate cashing possibilities. 2. Use a new random key for each encryption. 3. Instantiate a new encryptor instance for each encryption. 4. Do not use the first time from any series of tests. – zaph Oct 22 '17 at 19:03
  • @blafasel wow, on linux there is the string aesni but in raspbian os not. So i have to make analysis on the raspberry, right? On raspberry there is only this:name : aes driver : aes-generic module : kernel priority : 100 refcnt : 1 selftest : passed internal : no type : cipher blocksize : 16 min keysize : 16 max keysize : 32 – narraccino Oct 23 '17 at 10:23
  • @narraccino One last remark. I found some hints for switching crypto hardware support on raspi at [raspberrypi.org](https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=141566). And I successfully deactivated hardware support inside a VM running under KVM on an INTEL processor. Each VM has a XML descriptor containing an element `domain/cpu`. By adding `` I was able to create a VM without AES hardware support. – blafasel Oct 27 '17 at 08:43
  • @blafasel - I have not observed AES-256 run faster than AES-128 on commodity hardware. I've implemented AES using C-based intrinsics on Intel, ARM and Power8 machines. AES-256 is usually 0.2 to 0.4 cpb slower than AES-128. – jww Oct 29 '17 at 20:14
  • For Java, you should use JMH for performance testing: http://tutorials.jenkov.com/java-performance/jmh.html – Ram Patra Mar 21 '18 at 13:50

0 Answers0