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.
Riptides enforces post-quantum hybrid key exchange (X25519 + ML-KEM-768) on every internal mTLS handshake — via the kernel module, without touching application code or TLS configuration. 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.
Enable post-quantum hybrid mode in the Riptides kernel module. The module negotiates X25519MLKEM768 hybrid key exchange for every mTLS handshake it handles. No application restart, no TLS library changes.
Enable per service or per namespace. Peers that don't support PQC hybrid key exchange fall back to classical ECDHE — no broken connections. Verify actual negotiation with the safetls inspector before expanding coverage.
With PQC hybrid key exchange enforced at the kernel level, session keys can't be recovered by running Shor's algorithm against recorded handshakes. Traffic captured after enabling Riptides PQC mode is safe against retroactive quantum decryption. Traffic captured before enabling it is not — which is why starting today 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 provides per-connection visibility into negotiated TLS parameters — version, cipher suite, key exchange group. When the compliance question arrives, the answer is a query, not an assumption.
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.
A service mesh adds a sidecar to every pod to handle mTLS. That's a substantial operational footprint — and most service mesh implementations don't yet ship post-quantum hybrid key exchange in production configurations. Riptides handles mTLS at the kernel module level, already running on your hosts, with post-quantum mode ready to enable.
Internal service-to-service mTLS is the highest-value target for harvest-now, decrypt-later. You own both ends — no need to wait for industry-wide PQC adoption. Enable post-quantum hybrid mode on your most sensitive internal traffic paths first: auth services, secrets management, internal APIs that carry PII.
| 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 |
| 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 →
Kernel-level identity and enforcement. No code changes. Deploy in minutes.