is DES Faster Than AES on software

Question

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

Answer 1

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_TABLES undefined; 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.

Answer 2

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.