On Sat, 2019-04-13 at 15:46 +0000, Nikos Mavrogiannopoulos wrote: > 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? Oh, I agree. The recurring theme over more than a decade that I've been working on OpenConnect, has been "I don't want to have to do this. You can't expect application authors to get this right", and pushing things back to the crypto libraries to do it properly. While that is still my initial instinct, there are a couple of details which potentially make it different this time. Firstly, this *is* the upstream code from OpenSSL. I could set up a CI task to check that our perl scripts in the aesni/ directory are precisely matching what's in OpenSSL master, to make sure I keep up to date. And the interesting parts are AES-NI which is basically done in the CPU anyway; not a lot of scope for updating that. Sure, there's a SHA1 block hash function too, and I've even had to write my own sha1_update wrapper to feed blocks to it, but those are fairly simple. Secondly, this isn't a particularly generic requirement. The ESP encrypt-then-hmac scheme is *different* to TLS, and although I can use the same low-level core ASM routine which takes independent pointers for the CBC and SHA operations, it's not clear that there's much potential for re-use in a high-level routine that does it specifically for ESP. I *might* look at adding that to EVP_aes_128_cbc_hmac_sha1() in OpenSSL, but that wouldn't solve it for the GnuTLS build. On the whole, I think it's probably sane enough to use the Cryptogams asm functions. But sure, I'll make it opt-out.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ openconnect-devel mailing list openconnect-devel@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/openconnect-devel
