AES Java Encryption Performance Benchmarks
AES Java Encryption Performance Benchmarks - Gerrit Jansen van Vuuren - Medium
AES CBC+HMAC and GCM performance benchmarks for Java JCE, Bouncy Castle, Commons Crypto and Clojure Buddy.OverviewWhen considering which encryption scheme and library to use, ‘correctness’ is always the most important factor. The next important factor is performance.Why should we care about performance? encryption is slow anyhow right, but how slow? And how much is due to just library implementation decisions? A slow library doesn’t make the encryption scheme more secure.Performance is important. So much that there even exists special processor instructions for it on some platforms¹-². Using a slow library or too slow a scheme will cause unnecessary response delays, require a higher hardware investment. and may just be impractical on some systems.Native processor support can make a big difference in numbers, and libraries that use them, and when available, can show huge performance boosts over other libraries that do not. The most common of these instruction sets is Intel’s AES-NI. Java’s JCE providers make use of AES-NI when available since java 1.8⁵. For GCM PCLMULQDQ¹¹ instruction support was added in java 1.9¹²For this exercise I wanted to run a series of benchmarks for the most common Java encryption libraries (and I sneaked one in from the Clojure community), and see how they perform with a practical configuration.I used authenticated encryption only, so for AES CBC this means CBC+HMAC and GCM is already authenticated so is used as is.Enough talking, show me the numbers:Benchmark Results