In Jitsi Videobridge (https://jitsi.org/Projects/JitsiVideobridge), a WebRTC video conferencing router, encryption and packet signing were among the most expensive components in terms of CPU intensity. We therefore set out on a journey to optimize them as much as possible.

We would like to share this journey with the Java FLOSS community.

We are going to present a comparison we have made on the execution times of popular open source implementations of AES and SHA-1 in search of the best performer. Our reference implementations are provided by the pure-Java Bouncy Castle cryptography APIs. Our contenders are an assortment of widely-used Java and cross-platform C code: the SunJCE security provider optimized by Java Runtime Environment (JRE) 8, the Mozilla Network Security Services (NSS) libraries employed through the SunPKCS11 security provider and the OpenSSL Crypto library accessed with the help of the Java Native Interface (JNI).

We're going to pit software against hardware in our examination how we can leverage the Advanced Encryption Standard New Instructions (AES-NI).

We're going to look at the performance compromises of transferring bytes between Java and C. Can we beat Java's intrinsics? Will Java New/Non-blocking I/O (NIO) be better?