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 →
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 implements hybrid key exchange that combines classical algorithms with NIST-standardized post-quantum algorithms including ML-KEM (formerly Kyber). Hybrid mode means connections are secure against both classical and quantum attacks, and fall back gracefully if a peer does not support post-quantum algorithms.
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.