[HN Gopher] The State of OpenSSL for pyca/cryptography
       ___________________________________________________________________
        
       The State of OpenSSL for pyca/cryptography
        
       Author : SGran
       Score  : 20 points
       Date   : 2026-01-14 22:04 UTC (56 minutes ago)
        
 (HTM) web link (cryptography.io)
 (TXT) w3m dump (cryptography.io)
        
       | formerly_proven wrote:
       | > Finally, taking an OpenSSL public API and attempting to trace
       | the implementation to see how it is implemented has become an
       | exercise in self-flagellation. Being able to read the source to
       | understand how something works is important both as part of self-
       | improvement in software engineering, but also because as
       | sophisticated consumers there are inevitably things about how an
       | implementation works that aren't documented, and reading the
       | source gives you ground truth. The number of indirect calls,
       | optional paths, #ifdef, and other obstacles to comprehension is
       | astounding. We cannot overstate the extent to which just reading
       | the OpenSSL source code has become miserable -- in a way that
       | both wasn't true previously, and isn't true in LibreSSL,
       | BoringSSL, or AWS-LC.
       | 
       | OpenSSL code was not pleasant or easy to read even in v1 though
       | and figuring out what calls into where under which circumstances
       | when e.g. many optimized implementations exist (or will exist,
       | once the many huge perl scripts have generated them) was always a
       | headache with only the code itself. I haven't done this since 3.0
       | but if it regressed so hard on this as well then it has to be
       | really quite bad.
        
       | woodruffw wrote:
       | I think this part is really worth engaging with:
       | 
       | > Later, moving public key parsing to our own Rust code made end-
       | to-end X.509 path validation 60% faster -- just improving key
       | loading led to a 60% end-to-end improvement, that's how extreme
       | the overhead of key parsing in OpenSSL was.
       | 
       | > The fact that we are able to achieve better performance doing
       | our own parsing makes clear that doing better is practical. And
       | indeed, our performance is not a result of clever SIMD micro-
       | optimizations, it's the result of doing simple things that work:
       | we avoid copies, allocations, hash tables, indirect calls, and
       | locks -- none of which should be required for parsing basic DER
       | structures.
       | 
       | I was involved in the design/implementation of the X.509 path
       | validation library that PyCA cryptography now uses, and it was
       | _nuts_ to see how much performance was left on the ground by
       | OpenSSL. We went into the design prioritizing ergonomics and
       | safety, and left with a path validation implementation that 's
       | both faster and more conformant[1] than what PyCA would have
       | gotten had it bound to OpenSSL's APIs instead.
       | 
       | [1]: https://x509-limbo.com
        
       ___________________________________________________________________
       (page generated 2026-01-14 23:00 UTC)