Introducing pqprobe: Finding the Quantum Vulnerabilities Everyone Missed

January 28, 2026

We built pqprobe to answer a simple question: is your cryptography ready for quantum computers?

Today we're launching with a case study in what the tool finds when security marketing doesn't match implementation.

TL;DR

Claim Finding
“Post-quantum cryptography by default” FALSE for application layer
“X25519MLKEM768” in codebase NOT PRESENT (TLS-only, external)
“Two layers, independent protection” Layer 2 has ZERO PQC
“Full Matrix E2EE stack” 100% classical, quantum-vulnerable

The accurate statement: “Matrix on Cloudflare Workers, with PQC TLS for transport security. Matrix E2EE remains classical.”

The Target

On January 27th, Cloudflare published a blog post announcing a “post-quantum Matrix homeserver” running on Workers. By the next day, the Matrix community had identified problems: AI-generated code with authentication gaps, misaligned ASCII diagrams, claims of porting software from databases it never used.

The Matrix Foundation addressed the implementation gaps. What they didn't examine was the post-quantum claim itself—which is where pqprobe is needed.

Cloudflare Blog Claims

“Every connection is protected by post-quantum cryptography by default.”

“X25519MLKEM768 — a hybrid combining classical X25519 with ML-KEM, the post-quantum algorithm standardized by NIST.”

“Two layers, independent protection.”

Cloudflare's TLS is post-quantum. That's real. They've done good work there. But Matrix E2EE is not Cloudflare's TLS.

What pqprobe Found

We scanned 64 TypeScript files in 52ms:

$ pqprobe-static scan ./matrix-workers

QUANTUM-VULNERABLE CRYPTOGRAPHIC PRIMITIVES DETECTED

Severity    Count   Category
────────────────────────────────────────────────────────────
CRITICAL    14      Placeholder crypto implementations
                    (seed-as-keypair, hash-as-signature)
HIGH        17      Shor-vulnerable asymmetric crypto
                    (Ed25519, Curve25519, ECDSA, RSA)
MEDIUM      101     Classical signing operations (6)
                    Crypto key storage access points (94)
                    Documentation claims vs reality (1)
LOW         2       Grover-reduced symmetric (AES-GCM)
INFO        4       Grover-reduced hashing
                    (SHA-256, HMAC, PBKDF2)
────────────────────────────────────────────────────────────
Total       138
PQC Found   0       NONE DETECTED

Full scan results: JSON | SARIF

Zero post-quantum cryptography in the application layer. Seventeen instances of Shor-vulnerable asymmetric crypto in the code—matching exact algorithm identifiers like 'ECDSA', 'P-256', and ed25519. Fourteen critical findings where the cryptography isn't just quantum-vulnerable—it's placeholder code. Comments like // Placeholder signature - in production use Ed25519 next to code like const signature = hash;.

The Two Layers

The blog describes “two independent layers of protection.” Here's what each layer does:

Layer 1: Transport (TLS)

  • Algorithm: X25519MLKEM768 (post-quantum hybrid)
  • Protects: Data in transit between client and Cloudflare edge
  • Terminated at: Cloudflare's servers

Layer 2: Application (Matrix E2EE)

  • Algorithm: Curve25519 + Megolm
  • Protects: Message content, end-to-end
  • Keys stored in: D1 database, KV namespaces

PQC TLS protects against an adversary passively capturing TLS sessions on the wire, waiting for quantum computers to decrypt them. That's a real threat, and Cloudflare's TLS addresses it.

It does not protect stored cryptographic material.

Harvest Now, Decrypt Later

The threat model driving PQC adoption is harvest-now-decrypt-later. Nation-states capture encrypted data today, store it, decrypt it when cryptographically-relevant quantum computers arrive—estimated 2030-2040.

Here's what's harvestable from this Matrix server:

From D1 database:

  • events table: Megolm ciphertext (Curve25519-based key exchange)
  • device_keys: Ed25519 public keys
  • one_time_keys: Curve25519 public keys
  • cross_signing_keys: Ed25519 public keys
  • key_backup_keys: Encrypted session keys

From federation traffic:

  • Ed25519-signed events between homeservers
  • Server signing keys

Shor's algorithm solves the discrete logarithm problem efficiently. Given a Curve25519 or Ed25519 public key, derive the private key. The one-time keys in KV storage allow reconstruction of every Olm session, every Megolm session key, every message. The device signing keys allow forging any device, impersonating any user. The federation server keys allow forging historical events.

PQC TLS protects none of this. The keys aren't in transit. They're at rest.

Who Cares

Cloudflare described their target audience like this:

“government messaging systems, open-source communities, and privacy-focused organizations”

These are precisely the targets of harvest-now-decrypt-later. The timeline for political persecution often exceeds the timeline for quantum computing. Organizations whose threat models include nation-state adversaries with long time horizons need accurate information about what is and isn't protected.

What Actual PQC Matrix Would Require

For a “post-quantum Matrix homeserver” claim to be accurate:

  • ML-KEM for Olm key agreement (replacing Curve25519)
  • Dilithium or SLH-DSA for device/server signing (replacing Ed25519)
  • Hybrid classical+PQC modes for the migration period
  • Updates to every Matrix client

The Matrix spec doesn't support this yet. No homeserver implements it.

Calling a classical Matrix implementation “post-quantum” because it runs behind PQC TLS is like calling the filing cabinet in your home safe from attack because you drive an armored car to work.

Additional Findings

pqprobe's deeper scan caught issues beyond the post-quantum claim:

  • 94 access points across 10 stores (representing every code path that reads or writes quantum-vulnerable key material): SELECT, INSERT, UPDATE operations touching key material in D1 tables (6), KV namespaces (3), and Durable Objects (1).
  • Documentation mismatch: README claims Argon2id for password hashing. Code uses PBKDF2. pqprobe scans markdown for crypto claims that don't match implementation.

Why We Built pqprobe

Security claims are easy to generate. Verification requires tooling.

pqprobe scans your codebase and reports what's quantum-vulnerable, what's quantum-resistant, and what's missing.

Try it on your own code: pqprobe.com

pqprobe found 138 issues in 52ms. This post took longer to write than to disprove the marketing.

← All [PQ]files