If you run a Cryptsoft C or Java product on OpenSSL 3.5+ or Bouncy Castle 1.81+, you already have ML-KEM, ML-DSA and SLH-DSA. Here's the work behind that sentence — in the OpenSSL Corporation, in the KMIP standard, and in a five-day multi-vendor interop test.
NIST published the initial public drafts of its PQC standards and then finalised them far faster than the three-or-four-year cycle everyone had planned around. When the schedule compressed, priorities inside the OpenSSL project were redirected so that OpenSSL 3.5 would carry all three algorithms: ML-KEM, ML-DSA and SLH-DSA — with the key exchange in hybrid mode, classical and post-quantum together, the same construction the browser vendors adopted.
It was a genuinely collaborative effort inside the OpenSSL Corporation with external contributors: Paul and Shane from Oracle helped with SLH-DSA and ML-DSA, and Victor did the ML-KEM. Cryptsoft's contribution was not code — it was the testing, the coordination, and the project management, carried through three to four months of engineering calls that had people up at midnight. On the Java side, the same three algorithms landed in Bouncy Castle 1.81.
Cryptsoft's C and Java products use the versions of the underlying toolkits that carry the post-quantum algorithms — and they do it by default. There's no separate PQC edition and no feature flag to hunt for: upgrade the toolkit underneath, and the algorithms are available across the client and server SDKs.
There's a second, quieter benefit for mixed estates. If you're in an environment where your KMIP clients can't do these algorithms yet, you can ask the KMIP server to do them for you. Upgrade the server first, and post-quantum key material becomes available to every client that talks to it — while the clients migrate on their own schedule.
Toolkits aren't enough if the protocol can't carry the algorithms, so the same period saw ML-KEM, ML-DSA and SLH-DSA support added into the KMIP specification — OASIS standards-body work. And rather than inventing new conformance tests, we converted the tests NIST already defines for its Cryptographic Module Validation Program — the ones a vendor must pass for FIPS 140-3 validation — into KMIP tests, and made sure KMIP could express everything those tests require. Testing isn't the same as normal use; now the standard supports both.
From 3–7 March 2025, the results all published at kmip-interop.org, a multi-vendor KMIP 3.0 PQC interoperability test put the whole stack under load:
The test verified hybrid TLS support across the board. It also surfaced honest gaps: at test time the C# SDK didn't yet support the hybrid KEMs, and some of the Tiny SDKs couldn't do hybrid TLS because the underlying stack wasn't there. Both have since been closed — but that's what an interop test is for: finding the edges in March rather than in your production rollout.