OpenSSL vs SunJDK on AES-NI support

After investigating the implementation of AES-NI support in SunJDK 7u25+ and OpenSSL 1.0.0c+ and I found out the reason why SunJDK's implementation of CTR mode and CBC decrypt mode is slower than Openssl's implementation even if they are both based on AES-NI. In OpenSSL's implementation, for parallelizable modes, such as CTR, CBC decrypt, it interleaves the AESENC/AESDEC(AES-NI instruction) instructions working on independent blocks to make use of super pipeline for better performance and the interleave level can reach 6 for CTR mode and 8 for CBC decrypt. While in SunJDK's implementation, it only interleaves AESENC/AESDEC instructions for CBC decrypt on 64-bit systems and the interleave level is only 4.

While if you use AES-NI to implement a JCE provide, then for small block size, SunJCE wil be faster. The reason is that SunJCE is part of JVM, so it can make use of intrinsic to eliminate the JNI cost. For small block size, JNI cost account for a large proportion of the overal cost. While for larger block size, SunJCE will be slower as it didn't fully interleave the AESENC/AESDEC instructions as explained above. But there is no technical reason why SunJCE hasn't done so. Maybe in the future version, SunJCE will improve this.