Awesome article, some return from the field

Posted Jan 15, 2026 15:02 UTC (Thu) by Tarnyko (subscriber, #90061)
In reply to: Awesome article, some return from the field by hkario
Parent article: The State of OpenSSL for pyca/cryptography

Sure I agree, and this was also my point: 3.5 seems to be only 3x slower, and mostly during key parsing/negotiation phases (well, for negotiation it is logical to assume, but the latest article doesn't mention it...feel free to correct me if needed).
I don't develop general-use client/servers, so I don't rely so much on it: in short, it is not a deal breaker.

What could be a deal breaker in the future though, would be ecosystem fragmentation: if people start to drift away from OpenSSL, we're not assured to get it in all future development toolchains. Hence why the - currently unused - backend swap option, that I hope not having to use personally.

to post comments

Awesome article, some return from the field

Posted Jan 15, 2026 16:23 UTC (Thu) by hkario (subscriber, #94864) [Link] (4 responses)

What is expensive in 3.x compared to 1.x is algorithm _fetching_ that's because the 3.x series supports providers, so a lot more stuff needs to be done through generic APIs, not through algorithm-specific APIs. And then the library needs to fetch the concrete implementation and validate all those parameters.

When you compare reusing the same object (without re-fetching the algorithm and re-initializing the algorithm) on 1.x with 3.x then there are minuscule (single percentage point) differences between them: here's example of what happens if you don't use the API in optimal way: https://github.com/openssl/project/issues/1681

Could "optimal" be easier? maybe. But there's always balance between many factors: ease of use, how generic is the API, how easy is to provide the backend...

Upstream OpenSSL decided that having an easy way to add completely new algorithms (or new implementation of algorithms) should be easy, as that allows use of hardware accelerators, PKCS#11 modules, experimental crypto, national algorithms, etc. without having to include them in OpenSSL proper. For some people it's important, for others it's not.

Awesome article, some return from the field

Posted Jan 15, 2026 16:33 UTC (Thu) by Tarnyko (subscriber, #90061) [Link] (3 responses)

Thanks for the link to the benchmark: I value such feedback a lot.
In this case, I can confirm the impact on my specific use case is minimal (algorithm initialization is sparse, mostly done at program startup) and my concern is 99% about ecosystem.
I probably use the deprecated API signatures by the way; not that it matters if I read the results correctly.

Awesome article, some return from the field

Posted Jan 15, 2026 19:31 UTC (Thu) by hkario (subscriber, #94864) [Link] (2 responses)

Actually, there are much more comprehensive test results available: https://openssl-library.org/performance/

Awesome article, some return from the field

Posted Jan 16, 2026 5:06 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (1 responses)

Yes, these ones are really nice and a great improvement. Unfortunately they don't include 1.1.1 so it's not always visible where application faced a significant loss and what makes them complain.

Awesome article, some return from the field

Posted Jan 16, 2026 10:57 UTC (Fri) by hkario (subscriber, #94864) [Link]

They don't include 1.1.1 only for functions that are not in 1.1.1. Look for "evp_setpeer dh" as example of one that has 1.1.1 data...