While i have also done this kind of bundling in the past, In the long run it becomes a liability unless you are following up with new security issues on that mode/implementation. Having searched lots of applications for bundled crypto from the last decade or earlier all the benefits you see now will diminish quite fast. What about making it opt in? On April 13, 2019 10:48:52 AM UTC, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: >On Fri, 2019-04-12 at 00:05 +0300, David Woodhouse wrote: >> On Thu, 2019-04-11 at 22:14 +0200, Nikos Mavrogiannopoulos wrote: >> > Do you really want to implement crypto in openconnect? >> >> Hell no. I'm not *that* insane. >> >> This is the same core AES-CBC + SHA1 stitched implementation that is >> used in OpenSSL. It's generic enough to do what ESP needs; it's just >> that OpenSSL doesn't expose it in its generic form. >> >> It's providing basically the same CBC and SHA1 primitives that I'm >> using in the existing openssl-esp.c and gnutls-esp.c implementations; >> just that it does them both at once in the same function call. > >Using GnuTLS: > >Count reached 1583452 in 5s (1773 Mb/s) > >With the Cryptogams stitched code: > >Count reached 2370740 in 5s (2655 Mb/s) > >Do I *want* to do my own crypto? No, not really. But will I lift an >existing well-tested crypto implementation and hook it up to give me a >50% performance improvement? Yeah, probably :) -- Sent from my mobile. Please excuse my brevity. _______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
