I conducted a software based experiment for encrypting difference size of images using AES and DES. However unexpectedly DES encryption speed was higher than AES. is it possible that DES is faster than AES?. I also search the literature but could not come up with clear conclusion on this matter. Thanks
Yes, it is possible that AES is slower than DES. There is no limit to the slowness of un-optimized software!
Some factors that I have witnessed slowing a software AES implementation:
- not using tables for computation of the S-box(es) (an extreme example is the implementation there, when compiled with
BACK_TO_TABLESundefined; another possibility is using a formula intended for hardware or bitslicing, perhaps in order to remove timing variations).
- using hexadecimal ASCII (or binary) strings for everything, perhaps with the excuse that there is no built-in 128-bit type;
- using an interpreted language (one without built-in XOR will insure particularly poor performance)
- leaving debug code that dumps every intermediary result, even if that's effectively to /dev/null or equivalent;
- to a moderate degree, recomputing subkeys at each invocation when the mode of operation allows to factor that out;
- to a small degree, using 256-bit keys (it is hard to lose more than a factor of two with this one).
This is also applicable to DES to a large degree.
I should have mentioned that for decently and comparably optimized implementations, AES is typically faster than TDES and often than DES, and illustrated that with throughput; but that other answer does it nicely.
The raw throughput of a particular cipher (so ignoring any other factors like transmission, disk throughput etc) depends highly on:
- The level of optimisation in the software source
- The efficiency of the compiler used to produce the machine code
- The architecture where encryption is being performed (x86, MIPS, ARM and any CPU caching)
- Whether any architecture-specific accelerators (e.g. AES-NI) are being used
- How the cipher is used, especially the length of the data and how this is handled in memory along with any inter-process communication if present
As an example, a recent Intel Celeron produces the following benchmarks with OpenSSL 1.0.2k:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des ede3 17599.97k 17837.04k 17522.94k 17734.79k 17937.75k aes-128 cbc 47594.60k 52877.76k 53606.40k 119826.27k 119680.69k
While a Raspberry Pi 2 produces:
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes des ede3 2246.01k 2348.58k 2367.43k 2379.94k 2380.37k aes-128 cbc 13760.48k 15367.66k 15739.04k 15901.55k 15885.84k
Depending on the data size, AES outperforms 3DES by a factor of 2.7 - 6.6 in the Intel CPU with AES-NI, while the Pi stays at a fairly steady 6.1 - 6.6. This is as expected - AES was designed, and selected as a standard, because it lent itself well to efficiency of implementation even in small devices, and your observation is therefore intriguing.
Making blanket statements like "cipher x is faster than cipher y" aren't that useful without context regarding the implementation, and importantly the purpose. If I'm only interested in securing a VPN, either cipher would do fine if the link is only capable of 1Mbps throughput, and security of implementation would take precedence (as it should).
For the use case of image compression, unless these file are in the are gigabytes range, I would be surprised if the time taken to perform the encryption is the dominant concern.