This is a must-read.

https://cryptography.io/en/latest/statements/state-of-openssl/

#python #cryptography #crypto #openssl #opensource

@soatok I've neither been a fan of the python cryptography library nor OpenSSL, but this was an extremely refreshing read. I'm happy someone else has caught up on the substantial problems with OpenSSL. Thank you for sharing!

@soatok Holy crap on a cracker, I knew things at OpenSSL were bad, but *this* bad? 🤔

@soatok I am not a user of OpenSSL, being more down in the hardware, but these design choices are insane.

As if the developers are pleasuring themselves instead of trying to provide a finite implementation of a finite specification.

@soatok @kevin
"many OpenSSL source files are no longer simply C files, they now have a custom Perl preprocessor for their C code"

I... what?

@kurtmrufa @soatok The problems covered in OP is only the surface. I invite you to look at the spaghetti code hellscape that is the OpenSSL source code.

https://github.com/openssl/openssl/tree/master/crypto

@FritzAdalis @soatok @kevin As others have said this is not new, but the use of Perl for code generation seemingly has expanded.

@soatok Not 100% related, but are there sane alternatives for the openssl *command*? It's always a pain to look up subcommands and arguments, so I might as well just learn a new (set of) tool(s) for key and certificate manipulation.

Ah wow:

"Where we deem it desirable, we will add new APIs that are only on LibreSSL/BoringSSL/AWS-LC. Concretely, we expect to add ML-KEM and ML-DSA APIs that are only available with LibreSSL/BoringSSL/AWS-LC, and not with OpenSSL."

As one of MacPorts' LibreSSL maintainers, this is vaguely heartening, but also, stresses me out a bit more, since I think there are around 600-800 Portfiles that can probably be modified to use the dylib approach (something similar to adding this line to the Portfile:

depends_lib path:lib/libssl.dylib:openssl \

which facilitates MacPorts to defaulting to whatever TLS library is installed, and if that is LibreSSL as I do from a fresh MacPorts install, great!) but I haven't gotten around to modifying and testing those hundreds of Portfiles, let alone submitting Pull Requests which have gotten merged, even though it's been in the back of my mind for years and AFAIK, there are Trac issues for MacPorts that predate my helping out as a maintainer which express similar desires for more harmonious and widespread LibreSSL coexistence.

As it stands, I already feel as if I am burning the candle at both ends while contending with homelessness, over $12,000 USD in debt on my credit card and a paucity of income relative to my living expenses.

I'm also really not a fan of Python (though I admit, the last time it was dragged in as some dependency during an installation of something, at least it didn't try to install OpenSSL, as sometimes happens with some MacPorts), to understate it.

But y'know, cool! I think? Maybe?

I'm also, more or less certain that rpki-client prefers LibreSSL (no surprise, I think more or less all OpenBSD related projects do), but in the release notes for 9.7 (for which I recently submitted a Pull Request to update MacPorts' version to, so they're sort of fresh in my memory) there was mention of OpenSSL 4, which I guess is looming? Clemens also recently posted something to macports-dev about OpenSSL 3.6, and I admit, I pay less close attention to OpenSSL, but at least got the sense that other TLS library efforts are ongoing.

I probably don't want to know the answer to how many are using AWS-LC; I'd be vaguely curious how widely used BoringSSL is these days. Apple switched to LibreSSL an awfully long time ago now, but they seem as if they drag their feet on updating it and at the moment on macOS 26.2 it looks as if Apple are still shipping LibreSSL 3.3.6 (from March 15, 2022) whereas I'm running 4.2.1 (from October 30th, 2025, only three years and change more recent!) via MacPorts.

Having written as much, last year I think I saw yet another fork of OpenSSL and I may have even created a Trac issue to begin exploring it, but I can't remember the name of it off the top of my head at the moment and even after reading the slide deck from the conference where it was presented I think I had more questions than answers as to why it even came into existence.

@soatok

Wait, what?

For a concrete comparison of the verbosity, performing an ML-KEM encapsulation with OpenSSL takes 37 lines with 6 fallible function calls. Doing so with BoringSSL takes 19 lines with 3 fallible function calls.

I’ve recently been working on a CHERIoT port of mlkem-native. Doing an ML-KEM encapsulation with that library is, uh, one function call. Because that’s what MK-KEM does. How would you split it into even three functions in an API for users?

As an aside, I’ve been hugely impressed with those projects. When I raised PRs (don’t worry, I didn’t touch the crypto implementations):

• They run perf regression tests on a bunch of platforms automatically.
• They run model checkers on the C code to validate a bunch of correctness properties.
• They have a bunch of other proofs that I haven’t looked at that check security properties that are rerun automatically.
• They do all of the normal software-engineering things (code formatting, testing the build for a bunch of conditions).
• The people who review the code are helpful and engaged.

A library committed to security needs to make a long-term commitment to a migration to a memory safe programming language

It’s worth noting that there are tools for writing memory-safe C, which can be a better choice for portability (especially to embedded targets). The EverCrypt project produced C code, but effectively as an intermediate representation from their memory-safe source language. Both mlkem-native and mldsa-native use CBMC to prove memory safety. Neither of these approaches is applicable for arbitrary large C codebases but crypto libraries are not normal codebases.

The thing you can’t do is write a load of C with no tooling and then hope you get memory safety right later.

One of their criticisms (indirection layers killing performance) is not unique to OpenSSL. We were using mBedTLS for some of our demos. When we moved to a newer version, we found that the PSA abstractions that they’d built added about 70 KiB of binary size to a minimal build. For reference, the total code size for a minimal build before the update was about 20 KiB.

@soatok

> many OpenSSL source files are no longer simply C files, they now have a custom Perl preprocessor for their C code.

This horrifies me.

@soatok I've read it multiple times now and each time baffled at the OSSL_PARAM thing. The given reason (having the same ABI for different algorithms) is not a great reason for adding this much complexity, and any other reason I can think of (ABI compatibility between versions) can be done in less complex and error prone ways. It feels like the kind of solution someone comes up with who wants to show just how clever they are.

@soatok Good read.
"We do not fully understand the motivations that led to the public APIs and internal complexity we’ve described here. We’ve done our best to reverse engineer them by asking “what would motivate someone to do this” and often we’ve found ourselves coming up short."
The purpose of the system is what it does. Cui bono?

@soatok what do you think of libsodium

@nelson Libsodium is great.

@aoristdual @soatok This would get rejected from the Underhanded C Contest for being too obviously nefarious.

@david_chisnall @soatok I'm guessing "create", "do" and "destroy", for some object lifetime. How openssl makes it into 6 ... I dunno, maybe some BIO wrapper removal?

@dascandy @soatok

Hmm, possibly. But ML-KEM isn't like ML-DSA where you might choose to sign the entire document and not prehash, it's entirely operating on fixed-size objects (inputs and outputs).

I'm not sure about the algorithm details (and I treasure my ignorance, because it prevents me from thinking I can touch that code without breaking it), you might be able to separate the generate-key and encrypt-key steps, but my understanding was that they're fairly tightly coupled.