DEV Community

Daan Acohen
Daan Acohen

Posted on

Is Your Rust App Ready for the Quantum Age? Find out with pqctracer

#cybersecurity #rust #security #showdev

Quantum computers are coming — and when they arrive, much of today's encrypted internet traffic could be cracked wide open. That's not science fiction anymore; it's the reason NIST has already standardized post-quantum cryptography (PQC) algorithms, and why browsers like Chrome already negotiate post-quantum TLS handshakes by default.

But here's the uncomfortable truth: even if your client supports PQC, you have no idea whether your actual HTTPS connections are quantum-safe — unless you instrument them.

That's exactly the problem pqctracer solves.

A Quick Primer: What Is Post-Quantum Cryptography?

Classical key-exchange algorithms like X25519 are considered vulnerable to a sufficiently powerful quantum computer running Shor's algorithm. Once that threshold is crossed, any recorded TLS traffic from today could be retroactively decrypted — a threat known as "harvest now, decrypt later."

Hybrid schemes like X25519MLKEM768 defend against this by combining a classical algorithm with a post-quantum one. The connection stays secure even if one of the two is eventually broken.

The catch? PQC only works if both the client and the server support it. A client that prefers post-quantum handshakes will silently fall back to classical X25519 when the server doesn't support the hybrid group — and you'll never know unless you look.

You can also check whether your browser and a given web server support PQC over at quantumsafeaudit.com.

Introducing pqctracer

pqctracer is a reusable Rust library that wraps reqwest and rustls (with prefer-post-quantum enabled) to give you a TLS-aware HTTP client that captures the exact key-exchange group and cipher suite negotiated for every request.

No guesswork. No assumptions. Just facts straight from the TLS handshake.

The source code is available on GitHub: https://github.com/ConnectingApps/RustPqcTracer

Key features

  • Captures the negotiated TLS key-exchange group (e.g. X25519MLKEM768) per request
  • Captures the negotiated cipher suite (e.g. TLS13_AES_256_GCM_SHA384) per request
  • Built on reqwest + rustls with prefer-post-quantum support
  • Single shared connection-pooled client with lock-free per-request capture context across .await points

See It in Action

Here's all it takes to audit your outbound connections:

use pqctracer::TlsAwareClient;

async fn trace_host(tls_client: &TlsAwareClient, host: &str) {
    let url = format!("https://{}", host);
    println!("Requesting: {}", url);

    let req = reqwest::Client::new()
        .get(&url)
        .build()
        .expect("failed to build request");

    let result = tls_client.execute(req).await.expect("request failed");

    let group = result.group.as_deref().unwrap_or("Not available");
    let cipher = result.cipher.as_deref().unwrap_or("Not available");

    println!("Status code: {}", result.response.status());
    println!("Negotiated group: {}", group);
    println!("Cipher suite: {}", cipher);
}

#[tokio::main]
async fn main() {
    // Install aws-lc-rs as the process-level crypto provider (required when
    // `prefer-post-quantum` is enabled).
    rustls::crypto::aws_lc_rs::default_provider()
        .install_default()
        .expect("failed to install crypto provider");

    // Build the reusable TLS-aware client once.
    let tls_client = TlsAwareClient::new();

    trace_host(&tls_client, "www.google.com").await;
    println!();
    trace_host(&tls_client, "www.bing.com").await;
}
Enter fullscreen mode Exit fullscreen mode

And here's what you get back:

Requesting: https://www.google.com
Status code: 200 OK
Negotiated group: X25519MLKEM768
Cipher suite: TLS13_AES_256_GCM_SHA384

Requesting: https://www.bing.com
Status code: 200 OK
Negotiated group: X25519
Cipher suite: TLS13_AES_256_GCM_SHA384
Enter fullscreen mode Exit fullscreen mode

This output tells the whole story. Google supports the hybrid post-quantum group X25519MLKEM768 — so the handshake upgrades to a quantum-safe key exchange. Bing, on the other hand, only negotiates the classical X25519 group. Even though our client is fully PQC-capable, the connection to Bing gets zero post-quantum protection because the server doesn't support it yet.

Why This Matters for Your Services

If you're building or operating services that make outbound HTTPS calls — API clients, microservices, data pipelines — you probably have no visibility into what TLS groups are actually being negotiated. You might assume you're quantum-safe because you're using a modern TLS stack. But as the example above shows, that assumption is wrong half the time (or more).

pqctracer gives you the observability layer to:

  • Audit which third-party APIs and services you depend on actually support PQC
  • Track adoption over time as servers upgrade
  • Alert when a critical connection falls back to a classical group

Get Started

Add pqctracer to your Cargo.toml and start auditing your connections today. The crate is published at https://crates.io/crates/pqctracer and the full source code lives at https://github.com/ConnectingApps/RustPqcTracer.

The quantum threat isn't theoretical anymore — but the tools to defend against it are already here. Now you can see exactly where you stand.

Top comments (0)