OpenSSL is probably the most widely-used cryptographic library in the solar system.
(I’m not saying “on the planet” because at the time of writing [2026-04-10T17:00:00Z] there are three manned craft in space, two in low-earth orbit and one on its way back from the moon, plus close to 10,000 unmanned spacecraft whizzing around out there, and it’s a fair bet that OpenSSL is in use somewhere on at least one of them.)
OpenSSL 3.5 and 3.6, now updated to 3.5.6 and 3.6.2 respectively, introduced support for what are known as hybrid cryptosystems that combine existing, well-trusted cryptographic algorithms with new-fangled post-quantum algorithms that are supposed to be immune to the increased crypto-cracking power promised by a very specialized (but notoriously complex) type of device called a quantum computer.
Consider, for example, the process of key agreement, such as the up-front cryptographic dance done by your browser and a web server in order to come up with a secure, one-time, traffic-scrambling key for that connection only.
This process uses what’s known as public-key cryptography, which differs from conventional file-scrambling encryption by using not one but two keys, generated as a matching pair.
Very loosely speaking, what one key locks up, only the other can unlock.
The “lock-it” key is called the public key, because anyone can use it, and it can be revealed to everyone, as long as the matching “unlock-it” key, the private key, is indeed kept private.
That’s because you can generate a matching public/private keypair very quickly, thus making the algorithm practicable, but you can’t work backwards from the public key to extract the private key without expending unfeasible amounts of effort, such as millions of hours of computing time across millions of processor cores.
This extreme asymmetry in the computational effort needed to generate a keypair versus cracking a private key means that this sort of algorithm is also known as asymmetric encryption.
The asymmetry is there to ensure (again, loosely speaking) that even if attackers sniff out and record all packets in the protected network session, the only cryptographic material they will get hold of is each end’s public key.
With only the public keys to go on, they won’t be able to extract either of the private keys needed to complete the key exchange process.
That, in turn, means they won’t be able to extract the session key agreed on to scramble the actual data that was exchanged, so they won’t be able to decrypt and snoop on the original content.
The encrypted connection therefore remains secure, even though it was set up over an insecure, unencrypted network, perhaps even one owned and operated by an active adversary.
One of the most popular key agreement algorithms these days is the compact and efficient system known as X25519, devised more than 20 years ago by US crypto luminary Daniel Bernstein, which is considered both computationally elegant and mathematically solid, even after two decades of scrutiny and attack.
However, the asymmetric complexity of “reversing” the mathematics of X25519 to work backwards from a public key to a private key is today considered to be under threat – not because of an algorithmic flaw, but because of quantum computing.
The fear is that quantum computers, originally devised for investigating quantum mechanics directly at the quantum level, will maybe, just maybe, become powerful enough to unravel X25519’s elliptic curve arithmetic in hours, days, or weeks, where general-purpose computers might need centuries, millennia, or even longer to crack and recover just a single private key.
In truth, the jury is still out over whether quantum computers of the size and design needed for this sort of crypto-cracking can ever be built.
Some experts suspect that environmental noise, no matter how well shielded or corrected for, or other inescapable limitations will inevitably put an unsurpassble cap on the computational abilities of a device that relies on quantum-level behavior to work.
In other words, crypto-cracking using quantum computers may ultimately turn out to be prohibited by quantum physics itself.
But others, including industry giant Google (which admittedly has massive investments tied up in experimenting with quantum computers, and therefore a huge interest in talking up their future), are suggesting that we need to plan for 2029 as the year by which X25519 will no longer be safe enough.
In other words, we’re running out of time to switch to algorithms that are crackable neither by quantum nor by conventional computers.
One such algorithm is known as MLKEM, which uses the mathematics of module lattices (thus ML) to provide a key encapsulation mechanism (thus KEM).
This algorithm is officially endorsed as “future proof” beyond Google’s claimed deadline of 2029 by NIST, the US National Institute of Standards and Technology.
Unfortunately, these post-quantum algorithms turn out to be a bit of a double-edged sword.
After all, X25519 has been dissected, attacked and cryptanalyzed for more than 20 years without showing any algorithmic flaws, and took many years before it was considered unexceptionably trustworthy for everyday use.
Simply put, we now trust it because it has survived a huge amount of global scrutiny from a huge number of cryptanalyic experts who have openly published their research and findings over more than two decades.
On the other hand, most post-quantum algorithms are fairly new, or at least have had much less expert scrutiny than X25519 and other “pre-quantum” cryptosystems.
Even worse, a post-quantum algorithm called SIKE that survived several years of active study, and came very close to being endorsed as “officially safe for use” by NIST as part of the same project that approved MLKEM․․․
․․․suddenly and unexpectedly turned out to be useless.
In 2022, researchers published a paper, and corresponding crypto-cracking software, showing that SIKE could trivially be defeated in about an hour on a single CPU core.
Ouch!
This historical record therefore puts us on the horns of a dilemma.
Some cryptanalysts accept Google’s bold-though-still-secretive predictions that crypto such as X25519 will be readily crackable by 2029, and therefore say we should switch right now, before it’s too late.
Others warn that if we jump ship entirely to a system such as MLKEM, we may be running headlong into an even more severe crisis.
After all, if a complete break of the newer algorithm were suddenly discovered, as happened to SIKE, we’d be abruptly exposed – which would be an enormous irony if it happened after we’d ditched X25519 but before quantum computers were actually any good at cracking it.
Simply put, we could end up doomed if we do; doomed if we don’t.
One neat solution is to back ourselves both ways, for the next few years at least, by adopting what are known as “hybrid” key agreement schemes, such as the impressively-named X25519MLKEM768.
Admittedly, this system requires more computation (and more data to be transmitted in the form of public keys and key-agreement material in that up-front cryptographic dance), because it uses both algorithms in a combination that’s designed to be at least as secure of the stronger of X25519 and MLKEM768.
In other words, this system would only collapse catastrophically if a fast-enough quantum computer suddenly showed up that could take apart X25519, and a complete “break” of MLKEM were discovered pretty much at the same time, before we could reliably change either of them.
Belt and braces, if you like; or seat belts and airbags.
OpenSSL 3.5 and 3.6 support this sort of hybrid key exchange.
This means that clients and servers that support the combo-scheme can easily agree to use it, while optionally (for now, at least) falling back to X25519 or MLKEM alone if one end can only use (or insists on using) a single-algorithm cryptosystem.
Today’s versions of TLS, the transport layer security protocol now used almost exclusively for web connections (it’s the S in HTTPS) and email exchanges, support this hybrid approach, so it makes sense for each end to use a combo-scheme if possible, which is straightforward as long as each end supports both of the needed algorithms.
Unfortunately, the server-side code in that OpenSSL that decided whether to combine two algorithms in this way didn’t always work correctly.
This vulnerability is denoted CVE-2026-2673, as is described as, “OpenSSL TLS 1.3 server may choose unexpected key agreement group.”
Simply put, if a TLS client started its cryptographic dance by saying, for instance, “I’m prepared to accept X25519,” but the server had X25519MLKEM768 as its top choice, then the server might forget to ask the client to upgrade, even if the client would have been happy to do so.
Imagine that a pre-flight discussion along these lines․․․
CLIENT--> How about using X25519? <--SERVER Let me check my own preferences [Server to self: "I prefer X25519MLKEM768."] <--SERVER How about upgrading to X25519MLKEM768? CLIENT--> Sure! Let's use X25519MLKEM768 instead.
․․․ended up going like this:
CLIENT--> How about using X25519? <--SERVER Let me check my own preferences [Server to self: "I prefer X25519MLKEM768, but due to bug CVE-2026-2673, I've failed to figure that out, so I'll say nothing."] <--SERVER Sure! Let's stick with that.
Happily, this bug isn’t terribly serious, and is rated Low severity, because it can’t lead to either end being tricked into using an algorithm it wouldn’t otherwise have accepted at all.
But it is a reminder that configurational complexity is the enemy of correct cryptography.
The more options and combinations a cryptographic protocol or programming library is willing to support (and even more importantly, to negotiate automatically in real time), the more likely it is for something to go wrong, even though both ends would have been happy to do the right thing instead.
Unfortunately, if you run a server, insisting that all connecting clients adopt the latest and most secure configuration with no fallback could cause tension with your customers, so try not to be that sort of customer!
If you’re a customer, asking for servers that keep up with the latest and safest configuration options could end up in arguments with your service provider, so try not to be that sort of provider!
Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!
Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.
