Rémy,
> On Sep 30, 2016, at 09:50, Rémy Maucherat <r...@apache.org> wrote: > > 2016-09-30 15:26 GMT+02:00 jean-frederic clere <jfcl...@gmail.com>: > >>> On 09/29/2016 08:35 PM, Christopher Schultz wrote: >>> All, >>> >>> In the past few years, jfclere has been dong some performance testing >>> with JSSE-based crypto versus OpenSSL-based crypto, and it had always >>> been clear that the pure-Java crypto was slower by orders of magnitude. >> >> Correct, it is still slower (I need to redo my perf tests for the >> ApaccheCon in Seville to have the actual number to present :D). >> >>> >>> There was some concern that the hw-accelerated crypto wasn't actually >>> working as designed and that there may have been a bug causing the JVM >>> to fall-back to pure-Java instead of using the available hardware. >>> >>> Does anyone know if that issue was ever resolved? And if so, at what JVM >>> versions those patches were introduced? >> >> I remember that AES wasn't working as expected with old version of the >> JVM, but that is a long time ago, I complained and got a patch. > > it was GCM that was so bad. The fact that it didn't get noticed means that > JSSE is probably not used for real IMO, and it wasn't patched so long ago > either. Now they decided they're not sure if they care about ALPN (and > assuming they do, their API seems convoluted). So ... > > Anyway, as soon as you start adding accelerated native code to JSSE, you're > not doing anything that is more "pure Java" than using OpenSSL through JSSE. Agreed, though you no longer require OpenSSL directly (for your app), the JSSE wrapper, and the native shim to connect the two together. It's just like using Java's regular expression engine, which hopefully has a native implementation under the hood. -chris --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
