Someone is recording your mTLS traffic today to decrypt it when a quantum computer arrives. Riptides enforces post-quantum hybrid key exchange at the kernel level — no code changes, no redeployment.
Adversaries are passively capturing TLS handshakes and ciphertext today — no exploit, no alert. They will decrypt retroactively when a cryptographically relevant quantum computer exists. Every unprotected handshake is a permanent record.
Harvested mTLS handshakes don't just leak session data — they reveal SPIFFE IDs, certificate issuance patterns, and which workloads communicate with which. That architectural intelligence remains useful years after the sessions end.
The IETF will not define post-quantum cipher suites for TLS 1.2. Any service still speaking TLS 1.2 is categorically excluded from a quantum-safe future. There is no upgrade — only replacement.
Some runtimes now ship post-quantum hybrid key exchange on by default — but common TLS configuration patterns and framework helpers silently disable it. Most teams assume they're protected and aren't.
SafeTLS reads the ClientHello of whatever connects to it and grades what it finds — TLS versions, cipher suites, and whether a post-quantum key exchange group is on offer. Below is yours, live. No signup, no agent, no configuration.
Behind a TLS-inspecting proxy this is the proxy’s handshake, not your browser’s.
Couldn’t reach the inspector from here — run it yourself at safetls.riptides.io.
A current Linux client already offers a hybrid group. What it doesn’t survive is a line of TLS config — same machine, same curl:
curl -s https://safetls.riptides.io/api/inspect \
| jq '.observation.grade | {rating, post_quantum_offered}'No error, no warning, no log line. Now multiply that by every language, base image and vendored sidecar you run. Measured on Ubuntu 26.04, curl 8.18 / OpenSSL 3.5.5.
Riptides enforces post-quantum hybrid key exchange (X25519 + ML-KEM-768) on every mTLS handshake — via the kernel module, without touching application code or TLS configuration. There is no flag to switch on: hybrid is the default and only mode. Classical peers fall back gracefully.
Use safetls.riptides.io to inspect what your clients are actually advertising in their ClientHello — TLS versions, cipher suites, and whether any post-quantum key exchange groups are offered. No configuration, no agent, no signup.
There is no post-quantum mode to enable. The kernel module offers X25519MLKEM768 as its first key exchange group on every handshake it performs — internal mTLS and intercepted egress toward external servers alike. No flag, no application restart, no TLS library changes.
Every connection reports its negotiated key exchange group, so you can see which paths came up hybrid and which fell back to classical X25519 — a peer that doesn't support ML-KEM answers with a retry and the handshake completes anyway, so nothing breaks while the rest of your estate catches up.
Where the hybrid group is negotiated, session keys can't be recovered by running Shor's algorithm against a recorded handshake. Internal mesh traffic gets that on every handshake from the first one — no enablement step to schedule, no window where you think you're covered and aren't. Egress to an external peer that can't do ML-KEM still falls back to classical X25519, and those sessions remain harvestable, which is exactly why the negotiated group is worth reading rather than assuming. Traffic captured before Riptides was in the path stays exposed either way, which is why the start date matters.
The kernel module handles the TLS handshake. Go, Python, Java, Rust — any service making outbound mTLS connections gets PQC hybrid key exchange without touching TLS configuration, updating libraries, or redeploying.
X25519MLKEM768 hybrid key exchange retains classical ECDHE security even if ML-KEM were later found flawed. You are not trading one for the other — you are adding a second, independent layer on top.
Riptides reports the negotiated TLS parameters of every connection — version, cipher suite, and key exchange group, where X25519MLKEM768 marks a post-quantum handshake and X25519 a classical fallback. When the compliance question arrives, the answer is a query, not an assumption.
No userspace crypto daemon in the path: our FIPS 203 ML-KEM-768 implementation runs inside the kernel module, built on mlkem-native — the Post-Quantum Cryptography Alliance implementation whose C code is machine-proved memory- and type-safe.
Some runtimes now ship post-quantum protection on by default — but common TLS configuration patterns silently disable it, and you'd never know. For services written in other languages, it's entirely up to you. Riptides enforces post-quantum hybrid key exchange at the kernel level, regardless of what the application's TLS configuration says.
The meshes have caught up on the algorithm: Linkerd negotiates ML-KEM-768 by default between meshed pods, and Istio enforces X25519MLKEM768 once you set its PQC compliance policy. The difference is what you deploy to get there — a proxy next to every workload, and coverage that stops at the mesh boundary, so calls to unmeshed services and egress to external APIs stay classical. Riptides runs in the kernel module already on the host: no sidecar, no mesh membership, and the same hybrid group offered on intercepted egress too, so those connections come up post-quantum wherever the far end supports it.
Internal service-to-service mTLS is the highest-value target for harvest-now, decrypt-later. You own both ends, so nothing is waiting on industry-wide PQC adoption: put Riptides in the path on your most sensitive internal routes first — auth services, secrets management, internal APIs that carry PII — and those handshakes come up hybrid immediately, with no per-service TLS work.
| Classical TLS (today) | Riptides PQC Hybrid | |
|---|---|---|
| Key exchange algorithm | ECDHE (X25519 or P-256) | X25519MLKEM768 hybrid |
| Quantum resistance | Broken by Shor's algorithm | Resistant to known quantum attacks |
| Retroactive decryption risk | All stored traffic decryptable | Session keys unrecoverable from transcript |
| TLS version required | 1.2 or 1.3 | TLS 1.3 (enforced) |
| Code changes needed | Library updates, config changes per service | None — kernel module handles it |
| How it gets enabled | Per service, if the TLS stack supports it | Default-on — no flag, no per-service rollout |
| Record layer cipher | Peer's choice, commonly AES-128-GCM | 256-bit AEAD preferred (AES-256-GCM, ChaCha20-Poly1305) |
| Audit posture | "We think our runtime defaults are protecting us" | Per-connection negotiation log, queryable |
For a deep dive on Harvest Now, Decrypt Later, Shor's algorithm, and the full quantum threat model for workload identity, read our technical post: The Quantum Threat to Workload Identity and Why It Starts Today →
Today, adversaries can harvest encrypted TLS traffic and store it for decryption once a cryptographically relevant quantum computer exists. This is called a harvest-now, decrypt-later attack. Workload-to-workload mTLS traffic, API calls, and service connections made today could be decrypted in the future if the underlying key exchange algorithms (RSA, ECDH) are broken by quantum computing.
Riptides offers X25519MLKEM768 as its first key exchange group: ML-KEM-768, the NIST-standardized algorithm from FIPS 203 (formerly Kyber, at NIST security level 3), combined with classical X25519. SecP256r1MLKEM768 is offered as a second hybrid group. Because the exchange is hybrid, the session key derives from both parts, so connections keep classical security even if ML-KEM were later found flawed, and they fall back gracefully to X25519 if a peer does not support post-quantum key exchange. ML-KEM-768 runs inside the kernel module itself, on a FIPS 203 implementation built for kernel space.
No. There is no post-quantum flag, mode, or per-service setting. The kernel module offers the X25519MLKEM768 hybrid group on every handshake it performs, for internal mTLS and for intercepted egress toward external servers, from the moment it is in the path. You can confirm what was negotiated per connection: the reported key exchange group is X25519MLKEM768 for a post-quantum handshake and X25519 for a classical fallback.
No. Riptides enforces post-quantum hybrid key exchange at the kernel level. Your applications continue to use standard TLS APIs. The post-quantum negotiation happens transparently in the kernel module, invisible to the application. No library updates, no code changes.
Now. The harvest-now, decrypt-later threat means that sensitive workload traffic transmitted today is already at risk if quantum computing reaches cryptographic relevance in the next 10-15 years. The cost of retrofitting post-quantum cryptography into applications later is much higher than deploying it transparently at the kernel level today. NIST finalized its post-quantum standards in 2024, making this the right time to migrate.
Identity, access control, and a full audit trail for every agent and service — enforced on the host, with no code changes. Up and running in an afternoon.