QuStream vs post-quantum cryptography: a head-to-head for SSL/TLS

Two answers to the same quantum threat. PQC swaps the broken mathematics for harder mathematics and keeps the architecture; QuStream stops relying on the secrecy of mathematics at all. This sets them side by side — how each secures a link, how the first secret is delivered, what they cost on the wire and on the device, and where each one wins.

§1

The question

Today's web rests on TLS 1.3, and TLS 1.3 rests on two pieces of public-key mathematics: an elliptic-curve key exchange (X25519 or ECDH) to agree a session key, and an RSA or elliptic-curve signature to authenticate the server. Shor's algorithm breaks both. A sufficiently large quantum computer recovers the private key from the public one, so every session secured this way — and every session recorded today against that future machine — is exposed. With over four-fifths of the web served over HTTPS, the exposure is close to universal.

There are two ways to answer this, and they are genuinely different in kind. Post-quantum cryptography (PQC) keeps the TLS architecture exactly as it is and replaces the vulnerable primitives with new ones — lattice-based key encapsulation and lattice- or hash-based signatures — whose security rests on mathematical problems believed to be hard even for a quantum computer. QuStream takes the other road: it derives keys by walking a secret path through quantum-random material and leans, where it can, on information-theoretic security — secrecy that holds against unlimited computation because it depends on no unbroken problem at all.

The honest summary, stated up front: for the open web at scale, PQC is the right answer — standardised, drop-in, and increasingly mandated. For closed, high-assurance, long-lived, broadcast, or constrained networks, QuStream is the structurally stronger one, and the two compose: QuStream can use a single PQC handshake as its bootstrap and then move security to a tier no future computer can reach. The rest of this document earns those two sentences.

§2

How PQC secures TLS today

2.1  The hybrid handshake

NIST standardised the new primitives in 2024: ML-KEM (FIPS 203, formerly Kyber) for key establishment, and ML-DSA (FIPS 204, formerly Dilithium), SLH-DSA (FIPS 205, SPHINCS+) and the forthcoming FN-DSA (Falcon) for signatures. In TLS the deployed pattern is hybrid: the classical X25519 key exchange runs in parallel with ML-KEM-768, and the two shared secrets are concatenated into the normal TLS 1.3 key schedule. An attacker must break both to recover the session — so the post-quantum part can only help, never weaken. This is the configuration Google, Cloudflare and AWS already serve.

ClientHello and ServerHello carry hybrid X25519+ML-KEM key shares; the certificate path carries ML-DSA signatures. Client Server ClientHello key_share: X25519 + ML-KEM-768 · 1,216 B ServerHello ML-KEM ciphertext + X25519 · 1,120 B { Certificate } — ML-DSA chain { CertVerify } ML-DSA-65 sig 3,309 B · pk 1,952 B + chain / SCT / OCSP signatures → tens of KB Finished same architecture as classical TLS 1.3 · 1-RTT · same PKI / CA trust chain
Figure 1 · PQC hybrid handshake   The drop-in virtue is real: the message flow, the round-trip count and the trust model are unchanged. Only the contents grow. The key-agreement shares rise from tens of bytes to ~1.2 KB each (gold), and the authentication path — leaf signature, public key, intermediate signatures, certificate-transparency and revocation proofs — is where the bulk lands, often tens of kilobytes per connection.

2.2  What the security rests on

ML-KEM's secrecy rests on the conjectured hardness of the Module Learning-With-Errors problem; ML-DSA on a related lattice problem; SLH-DSA on the security of hash functions. These are computational assumptions, and that is the point to hold onto. They are believed to resist quantum attack, but "believed" is doing load-bearing work: structured-lattice cryptanalysis is roughly a decade old, far younger than the forty-odd years of confidence behind RSA and elliptic curves, and the field has already seen claimed quantum attacks on lattice problems appear and be withdrawn. PQC moves the wall and makes it higher. It does not remove the wall — and a recorded ciphertext stays vulnerable for as long as the assumption behind it survives.

This is why the harvest-now-decrypt-later threat is the organising concern. Surveys of cryptographers put a meaningful probability on RSA-2048 falling within the decade; whatever the exact odds, traffic captured today must stay confidential for the lifetime of the data it carries, which for state, financial and infrastructure records is measured in decades. PQC's bet is that the lattice assumption holds for that entire window. PQC standardised, drop-in, no provisioning — and only as durable as one unbroken assumption.

§3

Distributing the initial PDK

Every QuStream link begins from a shared secret state — the initial PDK (the path-derivation key of §2 of the technical introduction). After that first secret is in place, the ratchet, the public Q-blocks and the un-storable broadcast carry the link forward without ever distributing bulk key files again. So the whole question of "key distribution," which dominates a PQC deployment session after session, collapses for QuStream into a single one-time problem: how does each endpoint acquire PDK0? There are four practical channels, and they are not exclusive.

Four bootstrap channels converge on the initial PDK, which then feeds the QuStream security tiers. Pre-provisioned key fill factory / fill device · closed nets PQC-wrapped bootstrap one ML-KEM handshake delivers PDK₀ QKD optical link where fibre / free-space exists Out-of-band carrier smartcard · courier · QR Initial PDK₀ 256-bit secret state QuStream tiers take over ▸ one-time-pad · ITS ▸ bounded-storage · ITS ▸ ratchet · post-quantum no further key files shipped
Figure 2 · Bootstrapping the path   Four channels converge on a single 256-bit secret. Closed networks favour the key-fill route — you own every endpoint — giving the unconditional tier with no public-key step at all. The PQC-wrapped route is the open-web option: borrow one ML-KEM handshake to deliver PDK0, then leave the math behind.

3.1  The decisive asymmetry: how long the math must hold

The PQC-wrapped bootstrap deserves emphasis because it inverts PQC's central weakness. A pure-PQC link asks the lattice assumption to hold for the entire lifetime of every record it ever carries — decades. A QuStream link bootstrapped by one ML-KEM handshake asks the assumption to hold only at the instant of provisioning. Immediately afterwards the ratchet moves the state forward and, in continuous-stream mode, the bits the secret walk selects are bits no adversary could store — they have already vanished from the air. So even if the lattice problem were broken the day after bootstrap, a harvest-now-decrypt-later adversary recovers nothing: the only thing the broken handshake protected was a seed that has long since ratcheted away, and the traffic itself was never computationally protected to begin with.

PQC requires the assumption to hold for the full data lifetime; QuStream requires trust only at bootstrap. t₀ · provision data lifetime → decades PQC TLS lattice assumption must hold across the whole window ↑ break anywhere here → all harvested traffic exposed (HNDL) QuStream (PQC-bootstrapped) trust here information-theoretic from here on — no computer catches up
Figure 3 · The trust window   PQC's security depends on an assumption surviving the full lifetime of the data. A PQC-bootstrapped QuStream link depends on the same assumption holding for one handshake only; thereafter security is information-theoretic, so a future quantum advance against lattices cannot reach back to past traffic. This is the structural defeat of harvest-now-decrypt-later.
§4

Head-to-head: the security model

The first comparison is of kind, not degree. Classical TLS and PQC TLS share an architecture and a dependency on unbroken mathematics; they differ only in which mathematics. QuStream changes the dependency.

PropertyClassical TLS (RSA / ECDH)PQC TLS (ML-KEM / ML-DSA)QuStream
Security foundationFactoring / discrete logStructured-lattice / hash hardnessInformation-theoretic + PQC tier
Core assumptionComputational, ~45 yr studiedComputational, ~10 yr studiedNone (ITS tiers) · PRF/AEAD (comp. tier)
Quantum resistanceBroken by ShorBelieved resistantUnconditional (ITS) · post-quantum (comp.)
Harvest-now-decrypt-laterFully exposedResistant while assumption holdsImmune — bits vanish; bootstrap ratchets away
If the assumption fallsTotal, retroactive breakTotal, retroactive breakPast ITS/everlasting traffic stays safe
AuthenticationRSA / ECDSA signatureML-DSA / SLH-DSA signatureWegman–Carter one-time MAC (ITS) or sig
Forward secrecyEphemeral DHEphemeral KEMOne-way ratchet · everlasting in stream mode
PKI / CA dependencyRequiredRequired (PQ-PKI)Optional — none in pre-provisioned mode
Key supply per sessionFresh DH each timeFresh KEM each timeLocal derivation; no per-session asymmetric op
Topology fitInteractive 1:1Interactive 1:11:1, broadcast, and one-to-many native
Crypto-agility burdenLowHigh — may need re-migration if lattices weakenITS tier needs no re-migration, ever

Read down the right-hand column and the pattern is consistent: where PQC offers resistance conditional on an assumption, QuStream's information-theoretic tiers offer unconditional security, at the cost of needing the provisioning or the broadcast fabric that those tiers rest on. That trade — assumption-free security in exchange for infrastructure — is exactly why the deployment context decides the winner.

§5

Empirical cost: wire, latency, device

5.1  Bytes on the wire

The artifacts a session carries are the cleanest empirical contrast, because the numbers are fixed by the standards. ML-KEM-768 needs a 1,184-byte encapsulation key and a 1,088-byte ciphertext to agree the same 32-byte secret that X25519 agrees in 32 bytes each way. The authentication side is heavier still: ML-DSA-65 is a 1,952-byte public key and a 3,309-byte signature against Ed25519's 32 and 64; SLH-DSA trades a tiny 32–64-byte key for signatures from roughly 8 KB to nearly 50 KB. QuStream, once bootstrapped, carries no asymmetric material per session — each message key is derived locally from the public Q-block, so the marginal per-message secret on the wire is effectively nil.

Artifact (Level 3)ClassicalPQCQuStream
Key-agreement, each wayX25519 · 32 BML-KEM-768 ek 1,184 B / ct 1,088 Bpublic Q-block (shared) · 0 B secret
Signature public keyEd25519 · 32 BML-DSA-65 · 1,952 B— (no per-session PK)
SignatureEd25519 · 64 BML-DSA-65 · 3,309 B · SLH-DSA 8–50 KBone-time MAC tag · 16–32 B
Hybrid ClientHello share32 BX25519+ML-KEM · 1,216 Bn/a after bootstrap
Added auth path / handshake~0.2 KBtens of KB (chain+SCT+OCSP)~0 KB
Log-scale comparison of bytes on the wire for key agreement plus leaf authentication. key agreement + leaf authentication, bytes on the wire · log scale Classical ~160 B PQC · ML-DSA leaf ~7.6 KB PQC · SLH-DSA leaf ~50 KB · server-side compute up orders of magnitude when placed in the leaf QuStream ~32 B · derived locally
Figure 4 · Wire cost   Bar length is logarithmic; the numbers are exact. The classical baseline is a few hundred bytes; a lattice-signed PQC leaf is several kilobytes and a hash-signed one tens of kilobytes; QuStream's post-bootstrap per-session secret is a single 32-byte derived key with no asymmetric material on the wire at all.

5.2  Latency and the network

Size becomes latency at the packet boundary. A hybrid ClientHello near 1.2 KB approaches the ~1,400-byte MTU; the certificate path pushes well past it, so handshake messages fragment across multiple TCP segments — and a split ClientHello has been observed to confuse middleboxes and load-balancers badly enough to fail the connection outright. Cloudflare's deployment measurements are the reference points: adding roughly 9 KB to a handshake cost about 15% in handshake time, and crossing the ~10 KB mark forced an extra round trip that slowed the handshake by over 60%. First post-quantum connections typically add 50–200 ms, and on lossy links the penalty compounds — measured at roughly 13–19 ms of added handshake latency for every 1% of packet loss, because larger handshakes mean more segments to lose and retransmit.

QuStream sidesteps the entire class of problems. After bootstrap there is no per-session key exchange to fragment, no certificate chain to ship, and in continuous-stream mode no interactive handshake at all — two endpoints aligned by clock and PDK simply read the broadcast and arrive at the same key. The cost that PQC pays on every fresh connection, QuStream pays once.

5.3  On the device

The device story splits the PQC family. ML-KEM is computationally light — comparable to ECDH and often faster than RSA. ML-DSA is heavier but tolerable. The hash-based fallback SLH-DSA is brutal: place it in an interactive leaf certificate and signing dominates, driving handshake latency and server compute up by orders of magnitude. Falcon/FN-DSA signs compactly but needs constant-time floating-point arithmetic — without it, signing runs roughly 20× slower, and a careless implementation leaks the private key through timing during the handshake itself. On a Raspberry Pi or a microcontroller-class IoT endpoint, the larger keys, the lattice and big-integer math, and the memory footprint all bite.

QuStream's derivation is a bit-walk over a buffer followed by symmetric primitives — no lattice arithmetic, no big-integer exponentiation, no floating-point side-channel surface. It runs comfortably on the same constrained MCU that struggles with a PQC signature, which is why the smart-meter and tactical-radio profiles in the use-case set are realistic rather than aspirational. QuStream tiny endpoint, no asymmetric math; PQC ML-KEM light, signatures heavy, SLH-DSA/Falcon hazardous on constrained or interactive paths.

§6

At scale, and in closed networks

6.1  Where TLS's shape stops helping

TLS is an interactive, point-to-point protocol with a PKI behind it, and at scale that shape is the cost. Every fresh session re-runs the handshake and re-ships the authentication path; in a service mesh, a serverless tier, or dense machine-to-machine telemetry, the multiplier is the number of connections, and PQC multiplies the per-connection bytes. The genuinely hard part, as Cloudflare puts it, is that a single connection already carries several signatures — leaf, intermediates, certificate-transparency, revocation — and post-quantum signatures inflate every one of them. A post-quantum PKI must then issue, rotate and revoke certificates built from kilobyte-scale keys and signatures, and revocation lists and OCSP responses grow in step.

PQC TLS as a pairwise mesh with a CA; QuStream as a broadcast fabric with preloaded keys. PQC TLS in a closed enclave QuStream in a closed enclave PQ-PKI / CA n(n−1)/2 handshakes · certs to rotate QRNG PDK PDK PDK PDK PDK one broadcast · preloaded keys · no CA
Figure 5 · Topology in a closed network   PQC keeps TLS's pairwise mesh and its certificate authority, so cost scales with the square of the endpoints and with the size of every signature in the chain. QuStream maps a closed network onto a broadcast fabric with keys loaded once at provisioning — no pairwise handshakes, no certificate authority, and a one-to-many shape that TLS cannot natively express.

6.2  Why closed networks invert the trade-off

A closed network — a tactical link, a satellite downlink, a SCADA segment, an air-gapped enclave, a metering fan-out — changes two things at once, and both favour QuStream. First, you own every endpoint, so pre-provisioning a PDK at manufacture or via a fill device is straightforward; that unlocks QuStream's unconditional one-time-pad tier with no public-key step and no PKI to operate inside the enclave at all. Running a full post-quantum certificate authority inside a constrained or disconnected enclave is precisely the overhead these environments can least afford. Second, many closed networks are intrinsically one-to-many — a command broadcast, a downlink, a multicast control bus — a shape TLS's interactive handshake does not fit but QuStream's broadcast and bounded-storage modes were built for.

Longevity sharpens the point. A weapons platform, a grid controller or a satellite is fielded for twenty or thirty years and cannot be casually re-flashed. A pure-PQC system carries the standing risk of a second migration if lattice cryptanalysis advances — the assumption is young. QuStream's information-theoretic tier carries no such risk: unconditional security has nothing for future mathematics to catch up to, so a system fielded on it does not need to be re-secured against a cryptanalytic break that never threatens it. QuStream native fit for closed, broadcast, constrained, long-life nets; PQC native fit for the open, interactive, PKI-anchored web.

§7

The verdict

The thesis

Raise the wall, or remove it

PQC and QuStream are not competing implementations of one idea; they are two philosophies. PQC raises the wall — it keeps TLS exactly as it is and substitutes harder mathematics, betting that the new assumption outlasts the data. That bet is well-placed for the open web: PQC is standardised, drop-in, requires no provisioning, and is being mandated. QuStream removes the wall for the traffic that matters most — its information-theoretic tiers depend on no assumption a computer can defeat, so there is nothing to break and nothing to harvest. The price is infrastructure: provisioned key material or an un-storable broadcast. That price is cheap exactly where the stakes are highest — closed, high-assurance, broadcast, constrained, and long-lived networks — and the two compose cleanly, because a single PQC handshake makes an excellent bootstrap for a link that then needs no further mathematics.

Choosing between them, precisely stated

Reach for PQC where the deployment is the open web, the topology is interactive and 1:1, a PKI already exists, no key can be pre-shared, and regulation (CNSA 2.0, FIPS) calls for a standardised drop-in. Reach for QuStream where endpoints can be provisioned or share an un-storable broadcast, where the topology is one-to-many or broadcast, where devices are constrained, where systems are fielded for decades, or where harvest-now-decrypt-later against the highest-assurance traffic must be defeated by construction rather than by assumption. For the strongest posture of all, combine them: bootstrap QuStream with one PQC handshake and trust the mathematics for an instant, not a lifetime.

§8

In summary

Post-quantum cryptography secures TLS by swapping vulnerable primitives for lattice- and hash-based ones, keeping the architecture and the PKI but inflating every key, signature and handshake — and resting, still, on a computational assumption that must survive the full lifetime of the data. QuStream derives keys by walking quantum-random material from a single provisioned or bootstrapped secret, carries almost nothing on the wire thereafter, runs on the smallest devices, fits broadcast and one-to-many topologies natively, and offers tiers whose security no future computer can reach. PQC is the right answer for the open web; QuStream is the stronger answer for closed, constrained, broadcast and long-lived networks — and a PQC handshake is the cleanest way to start a QuStream link that, from its first message on, owes nothing more to unbroken mathematics.