Short answer: StreamSec Tools 4.x ships the NIST post-quantum algorithms — ML-KEM (FIPS 203), ML-DSA (FIPS 204) and SLH-DSA (FIPS 205) — wired into the protocols where they matter: hybrid key exchange in TLS 1.3 and SSH, post-quantum signatures in certificates and S/MIME. Not a research branch, not a roadmap slide: properties you can set today, interop-tested against OpenSSL.

THE THREAT HAS A DATE ON IT

A quantum computer able to break RSA and elliptic curves does not exist. Traffic recorded today, however, keeps — and an adversary that stores your TLS sessions now can decrypt them the day such a machine exists. That is the "harvest now, decrypt later" problem, and it makes key exchange urgent even though authentication can wait: a signature only has to be secure at the moment it convinces someone, but a session key has to protect its data for as long as that data matters. This is why the industry — and the published government migration timelines — move key establishment first, signatures second. StreamSec Tools follows the same order and covers both.

WHAT YOU CAN TURN ON TODAY

• TLS 1.3 hybrid key exchange (RFC 10024) — X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, plus pure ML-KEM 512/768/1024, selected with one property on the TLS components. Every hostile or malformed key share is validated and rejected with the exact alert the RFC prescribes.
• Post-quantum authentication in TLS 1.3 — ML-DSA (44/65/87) signatures in CertificateVerify, with certificates to match; modern classical EdDSA ships alongside it for the transition.
• SSH — post-quantum hybrid key exchange using ML-KEM in the SSH client and server.
• Certificates and PKI — X.509 certificates with ML-DSA keys, composite ML-DSA certificates tracking the IETF LAMPS drafts (for CAs that require a classical co-signature during the transition), certificate requests for KEM keys (RFC 9883), and PKCS#8 / PFX handling for all of them.
• CMS and S/MIME — SignedData with ML-DSA and EdDSA; EnvelopedData with KEM recipients (RFC 9629) for ML-KEM and composite ML-KEM — so a document encrypted for archival today is not the thing a future quantum computer reads first.
• SLH-DSA (FIPS 205) — the conservative, hash-based signature standard, for signatures whose lifetime is measured in decades. Hash-based signing is not new here: the library has carried Winternitz one-time signatures and the generalized Merkle scheme for years.

HYBRID MEANS NO REGRESSION

The hybrid groups run the classical exchange and ML-KEM in parallel and combine both secrets, so the session is secure if either algorithm holds. You are not betting your traffic on new mathematics; you are adding a second lock while keeping the one that has been attacked for forty years. That is the deployment posture the standards bodies recommend for the transition, and the one StreamSec recommends: when you enable post-quantum key exchange, enable a hybrid group first.

READINESS IS ALSO KNOWING WHAT NOT TO SHIP

Post-quantum standards are still moving, and a library can create migration debt by shipping too eagerly. StreamSec's policy is deliberate: post-quantum groups are opt-in, the stack never advertises a capability it lacks key material for, and it does not implement codepoints the IANA registries discourage or that exist only in expired drafts — which is why, for example, there is no composite-KEM TLS group: no standard defines one yet. When one is standardized, the plumbing underneath is already there. Readiness includes not having to un-ship anything.

PROVEN BY INTEROP, NOT BY PRESS RELEASE

• TLS 1.3: all three hybrid groups and pure ML-KEM, interop-tested against OpenSSL in both directions, alongside ML-DSA and EdDSA CertificateVerify
• CMS: ML-DSA and Ed25519 SignedData produced by StreamSec verifies in OpenSSL, and vice versa
• Composite algorithms validated against the official test vectors of the IETF LAMPS drafts

WHERE TO START

Three steps, in the order they pay off: enable a hybrid group on your TLS connections — that closes the harvest-now-decrypt-later window at the cost of one property; take stock of what you ship and how long its secrets must live (the SBOM page is about exactly that kind of inventory); and plan certificate migration with your CA — composite certificates exist precisely so that step does not have to happen in one jump. Talk to us if you want help sequencing it.