What Is PQST? The Beginner's Guide to Post-Quantum Secure Transport

CodexFuse Team · 2026-11-05T19:04:42.462Z · 21 min read min read

What Is PQST? The Beginner's Guide to Post-Quantum Secure Transport

What Is PQST?

What is PQST? PQST (Post-Quantum Secure Transport) is a post-quantum transport protocol proposed in a November 2026 IETF Internet-Draft: a session-primary datagram transport for secure tunnels that uses no classical public key cryptography, no hybrid key exchange, and no classical fallback. Its central rule is simple to state and strange to engineers used to today's tunnels: the cryptographic session is the persistent object, and the network path is a replaceable carrier.

A session can outlive the complete loss of every network path and be re-anchored on a new path with fresh post-quantum key material, without the tunnel, its addressing, its authorization, or the peers' authenticated identities changing.

PQST is a work in progress, not a standard. The core draft is revision -00, the first posting, dated 2 November 2026, and it expires on 6 May 2027 unless a new revision replaces it. It is a single-author individual draft by Clayton Henry, and its Standards Track label is an intent, not a grant: the author is still seeking a working-group home for it.

The draft family is three days old at the time this article was written, and this is the first plain-English explainer of it anywhere: an exact-phrase search for "what is PQST" returns only the drafts themselves, their datatracker pages, and the author-tools copies. That is the gap this article fills. It explains what PQST is, how a session outlives its network, what the cryptography and the costs look like, how it compares with WireGuard and TLS, and what the cohort layer adds for groups.

Checking that a file you downloaded is the file you think it is starts with a hash, and the SHA-256 hash generator is a free tool for exactly that check. And because secure tunnels ultimately run on servers, VPS hosting is the natural companion topic: a private server you control is where a tunnel endpoint, and one day possibly a PQST session, actually lives.

Why Does PQST Exist? The Problem With Sessions That Die With the Network

PQST starts from a moment every network engineer knows: the live cryptographic and transport state is gone. A process restarted. A device slept so long that keeping the state was not worth its cost.

A second gateway had to take the session up. In that moment, today's secure transports do not continue the same session; they start a new one, and whatever the old session held — its authorization, its bindings, its exporter values — has to be rebuilt or is simply lost.

The draft draws the comparison itself. QUIC keeps a connection across address and port changes, but a connection that ended is replaced by a new one. WireGuard keeps a configured peer and replaces traffic keys by repeated handshakes.

IKEv2 with MOBIKE moves a security association to new addresses, and a deleted association can be resumed from a ticket as a new IKE SA. PQST's claim is that the same session — identifier, authorization, exporter values — continues after the live state is gone.

The environments it names are the hard ones: denied, degraded, intermittent, and limited-bandwidth networks, including radio nets. The cohort draft puts it bluntly for groups: in disconnected, intermittent, and limited networks, a group service that dies with its server is of no use. PQST is designed for links that go away and come back, not for the stable data-centre links where today's tunnels already work well.

What Does "Session-Primary" Mean?

PQST inverts the layering most engineers carry in their heads: identity first, then cryptographic session, then the current network path. The session is the primary, long-lived object. Paths attach to it, detach from it, and may disappear entirely while the session stays meaningful.

That is what "session-primary transport" means: the session is the thing that persists, and the path is a replaceable carrier for it.

A session with zero paths is a defined state, not an error. Losing every path moves the session to RECOVERING and then DORMANT, discarding live keys, identifiers, and replay windows while keeping the continuity state a re-anchor needs. The draft defines the logical session independently of its paths and of its live key state: a continuity record keeps what a fresh post-quantum re-anchor needs, so the session identifier, the authorization it holds, and the bindings above it survive the loss of everything else.

The same exchange that establishes a session also recovers it, re-proves it, and ratchets it. Performed from nothing, it is the handshake. Performed from an existing session, it is a re-anchor, which creates the next generation of the session's secrets from the previous one plus a fresh post-quantum secret.

With a prekey exchanged in advance, a re-anchor costs no round trip at all.

How Does a PQST Session Start, Re-Anchor, and Recover?

The whole lifecycle fits in five steps. The first exchange is the expensive one; every step after it is cheaper, because the session already exists.

1. Anchor the session. The FRESH exchange establishes a session in one round trip to initiator data, with about 3.3 KB of anchor messages each way.
2. Carry datagrams. The data plane runs over UDP with 44 octets of per-packet overhead, the epoch and sequence number hidden, and identifiers derived rather than signalled.
3. Lose the path. When every path is gone, the session moves to RECOVERING and then DORMANT, keeping only its continuity record.
4. Re-anchor. The CONTINUE exchange rebuilds the session from the continuity record with fresh post-quantum key material: about 1.7 KB each way, one round trip, or none at all with a prekey.
5. Ratchet forward. Each re-anchor creates the next generation of the session's secrets from the previous generation plus a fresh post-quantum secret, giving forward secrecy and post-compromise security at the granularity of the re-anchors.

Two numbers make the shape of this design clear. A re-anchor's 1.7 KB is about half of the 3.3 KB a fresh establishment costs — 51.5%, by the drafts' own figures — because the continuity record already holds what a new handshake would have to prove from scratch. And the continuity record itself is small: about 5 KB between exchanges, about 2 KB where prekeys are regenerated from a local secret, and up to about 12 KB while an exchange is in flight.

Recovery has one honest limit the drafts state themselves: on very slow, lossy links, a recovery can complete as a new FRESH session that supersedes the old one instead of a CONTINUE of it. The session still continues in the sense that matters — same identifier, same authorization — but the mechanism falls back to a fresh anchor when the link will not carry a re-anchor.

What Cryptography Does PQST Use?

Long-term identities are ML-KEM-1024 keys, and a peer proves its identity by decapsulating. No signature is computed online in any exchange. ML-DSA-87 certifies identity keys offline where a deployment needs that, but the live protocol never signs.

That is the "post-quantum native" part of the name: there is no classical public key cryptography in the design at all, and no hybrid step that keeps a classical algorithm alongside the post-quantum one.

The cipher suite is ML-KEM-1024 for key establishment, AES-256-GCM for the data plane, HKDF and SHA-384 for key derivation, plus header protection. The drafts promise confidentiality, integrity, replay protection, and forward secrecy and post-compromise security at the granularity of the re-anchors, against adversaries with quantum computers. A generation's epochs share one lineage secret, and session-scoped exporter material lasts the session.

What PQST does not provide is just as deliberate. It provides neither reliable delivery nor congestion control: the traffic it carries brings its own. It needs no public-key infrastructure, no load balancer that understands it, no ticket store, and no synchronised clock beyond a loose agreement for gateway-group sealed records. If you want congestion control, that is a separate problem — one that other November drafts attack directly, as What Cuback is explains for TCP.

What Does PQST Cost? Overhead, Sizes, and the 44-Octet Header

The headline cost is 44 octets per packet: header, protected block, and tag, excluding the IP and UDP headers. Against the draft's default starting datagram size of 1,200 octets per path, that is 44 divided by 1,200, or about 3.7% of each datagram — a small, fixed tax that does not grow with the packet.

The establishment costs are one-off and measured in kilobytes. A FRESH anchor exchange moves about 3.3 KB each way; a CONTINUE re-anchor moves about 1.7 KB each way. Anchor messages travel in fragments of at most 1,183 octets by default, so a fresh establishment takes three fragments each way — 3,300 divided by 1,183 is about 2.8 — and a re-anchor takes two.

The drafts also report one measurement that must be read with its warning label attached. A forged FRESH message costs the responder about 40,000 ML-KEM-1024 decapsulations per second — roughly one core at a 1 Gbps line rate — but the overview states plainly that this is a measurement of the reference implementation on one machine, not a property of the protocol. The same caution covers the author's comparative recovery-delay measurements against WireGuard, Rosenpass over WireGuard, IKEv2 with MOBIKE, and MASQUE: they exist, and they are kept with the implementation's results rather than in the drafts, so no comparison numbers are published here.

PQST vs WireGuard: What's Different?

WireGuard describes itself as "an extremely simple yet fast and modern VPN that utilizes state-of-the-art cryptography," and it securely encapsulates IP packets over UDP, associating tunnel IP addresses with public keys. It is the modern baseline for a simple secure tunnel, and the draft measures PQST against it.

The difference is what survives. WireGuard keeps a configured peer and replaces traffic keys by repeated handshakes; when the live state is gone, a new handshake starts a new security association. PQST keeps the session itself — identifier, authorization, exporter values — and re-anchors it with fresh post-quantum key material.

WireGuard's keys are classical; PQST's identities are ML-KEM-1024 keys with no classical fallback at all.

That does not make PQST a WireGuard replacement. WireGuard is shipping, studied, and deployed at scale; PQST is a three-day-old -00 draft with a reference implementation available from its author on request and no public repository link. The comparison is useful for understanding the idea, not for choosing a tunnel today.

PQST vs TLS: Why Compare a Transport With a Channel?

TLS 1.3, specified in RFC 8446 in August 2018, lets client and server applications communicate "in a way that is designed to prevent eavesdropping, tampering, and message forgery." But its primary goal is a secure channel between two communicating peers, and the only requirement it places on the underlying transport is a reliable, in-order data stream. TLS is a channel that rides on a reliable stream; PQST is a datagram transport that runs directly over UDP. They sit at different layers, and the comparison is only meaningful if you keep that straight.

The same layering point answers the QUIC question. QUIC keeps a connection across address and port changes, but a connection that ended is replaced by a new one. PQST's session is the object that survives; QUIC's connection is the object that gets replaced. What MASQUE is shows the other side of the QUIC family: proxying traffic through QUIC, which is a different job from PQST's session continuity, and the two can be described in the same sentence without being rivals.

The arithmetic of age makes the gap visible. TLS 1.3 dates to August 2018, which is 8 years and 3 months before this article was written in November 2026. PQST is 3 days old.

One is the settled channel of the modern web; the other is a first-draft proposal for what a tunnel could look like when the session, not the connection, is the durable object.

What Is the PQST Cohort Layer?

The cohort layer applies the same idea one level up. The draft's own analogy is the cleanest way to say it: the cohort is to its members' sessions what a session is to its paths. A cohort member's sessions move, sleep, recover, and re-key on their own, and none of those events by itself requires a change of the cohort's membership.

Membership changes only on security events: admission, removal, revocation, and scheduled rotation.

One sequencer commits the membership, the policy, and a membership epoch together with that epoch's key, and only on security events. Members receive them inside their pairwise sessions, keep them through partitions, and return after dormancy or a restart without readmission — unless they were away longer than the group's expiry. A removal from the cohort closes that member's sessions with the sequencer; it does not close its pairwise sessions with other members.

This version specifies only the control plane — membership, policy, reachability, and member discovery. It specifies no group data plane: member-to-member traffic travels in ordinary pairwise PQST sessions, and a group data plane under keys derived from the epoch key is described as the direction of the next version. Unlike MLS, the cohort has a trusted sequencer that delivers the group's key, and post-compromise security comes from rotation, at once on removal.

The cohort layer is Experimental, and its maturity is thinner than the core's. There is one Go reference implementation, described as a research prototype, and the draft reports no independent implementation and nothing interoperated. What it does report is a census dated 2 November 2026: 0 failures in 100,002 cohort scenarios and 10,000 gateway-group scenarios, with 10,981,128 of 10,981,128 datagrams between undisturbed members delivered by the next window — 100% — and hinted returns resumed in a median of 100 ms and a 95th percentile of 1.1 seconds.

A census of a prototype is evidence about the prototype, not a deployment claim, and no adoption or deployment of the cohort layer is claimed anywhere in the drafts.

What PQST Is Not — and Its Stated Limits

PQST is not a standard, not a working-group product, and not a shipping tunnel. It is a single-author individual draft — Clayton Henry, writing from viaforge.ai — and the author is seeking a working-group home for the core protocol and implementation experience with both layers. Nothing in the drafts shows a vendor, a product, a deployment, or an IETF endorsement, and this article claims none of those things.

The implementation evidence is the author's own: a Go reference implementation covering the core specification including the test vectors, a second independent implementation in Python written from the specification text alone that reproduces every test vector and interoperates with the reference over UDP, and a discrete-event simulator running campaigns of up to a million generated scenarios. The repository is available from the author on request; no public repository link was found in the fetched text, so none is given here.

The drafts also state their own limits, and they are worth repeating because they are the difference between a proposal and a product. Recovery can complete as a new FRESH session superseding the old one on very slow, lossy links. Continuity records need durable storage with atomic replacement.

No UDP port is assigned or requested. A gateway group shares one replicated identity key, so compromise of one gateway is compromise of the group's identity. And no timing measurement is claimed for the constant-time or erasure properties.

Who Should Follow PQST, and Who Can Wait?

If you build or run tunnels, VPNs, or overlay networks, PQST is worth an hour of your reading time — start with the overview's sections 2 and 3, which the author says give an accurate mental model, and stop there if you only need the idea. If you plan post-quantum migration for a network that has to survive intermittent links, the session-primary model is the part to think about, because it changes what "the session survived" means. If you run hosting infrastructure, the honest position is to watch: a tunnel that survives path loss and restarts without re-authentication would change how failover is built, but nothing here is deployable yet.

Protocol watchers following the November 2026 IETF draft wave will find the same pattern elsewhere: new drafts proposing new session models for agents and networks, including MCP over MoQ, which carries agent protocol traffic over Media over QUIC. PQST belongs to that wave — a first draft, not a finished answer — and it should be read as one.

How to Read the Draft Family — and What Happens Next

The family is three documents. The core is draft-henry-pqst-00: 326 pages, intended Standards Track, containing the anchor exchange, the data plane, path management, dormancy and crash-consistent recovery, authorization, a state-object mechanism, and the registries and invariants that hold them together. The overview is draft-henry-pqst-overview-00: 22 pages, Informational, non-normative, defining nothing.

The cohort layer is draft-henry-pqst-cohort-00: 61 pages by its own table of contents, Experimental, containing the membership and policy control plane. All three were posted on 2 November 2026 and share the same six-month window, and all three carry the same IPR disclosure from the same day.

The overview's reading map is the practical part. A reader in a hurry can read sections 2 and 3 and stop with an accurate mental model. A security reviewer needs about 60 pages of the core; a transport reviewer about 65; an implementer the remainder, about 230 pages — of which the test vectors are 110.

Those three paths overlap rather than add up, but one piece of arithmetic is exact: the test vectors are 110 of the core's 326 pages, or about 33.7% — roughly one-third of the whole draft is worked examples. And the overview's own rule governs any conflict: it specifies nothing, and where any statement in it appears to conflict with the core or the cohort draft, those documents govern.

The next visible event is a -01 revision. The drafts' six-month window runs from their 2 November 2026 posting — 185 days, by the calendar — and a -01 would answer the questions a first draft always leaves open: whether a working group takes the core in, whether a second independent implementation of the cohort layer appears, and whether the comparative recovery measurements ever get published. Until then, the story is the idea, not a deployment.

What would change the story is concrete: a working-group home for the core, an independent implementation of the cohort layer that interoperates, or published numbers for the recovery comparisons the author currently keeps with the implementation's results. None of those exists yet, and this article will not pretend otherwise. For now, PQST is best understood as a sharply argued question — can the authenticated session itself survive after the network paths and the live cryptographic state are gone? — with a 326-page answer attached.

Sources

1. C. Henry, "Post-Quantum Secure Transport (PQST)", Internet-Draft draft-henry-pqst-00, 2 November 2026. https://datatracker.ietf.org/doc/draft-henry-pqst/

2. C. Henry, "Post-Quantum Secure Transport (PQST): Overview and Reading Guide", Internet-Draft draft-henry-pqst-overview-00, 2 November 2026. https://datatracker.ietf.org/doc/draft-henry-pqst-overview/

3. C. Henry, "The Cohort Layer of Post-Quantum Secure Transport (PQST)", Internet-Draft draft-henry-pqst-cohort-00, 2 November 2026. https://datatracker.ietf.org/doc/draft-henry-pqst-cohort/

4. Datatracker history for draft-henry-pqst-00 (posted 2 November 2026). https://datatracker.ietf.org/doc/draft-henry-pqst/history/

5. Datatracker history for draft-henry-pqst-overview-00 (posted 2 November 2026; IPR disclosure noted). https://datatracker.ietf.org/doc/draft-henry-pqst-overview/history/

6. Datatracker history for draft-henry-pqst-cohort-00 (posted 2 November 2026; IPR disclosure noted). https://datatracker.ietf.org/doc/draft-henry-pqst-cohort/history/

7. WireGuard, "WireGuard: fast, modern, secure VPN tunnel" (project homepage). https://www.wireguard.com/

8. E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018. https://www.rfc-editor.org/rfc/rfc8446.txt

Frequently Asked Questions

What is PQST in simple terms?

PQST is a proposed post-quantum transport protocol for secure tunnels. Instead of tying a tunnel's security to a connection that dies when the network disappears, it makes the cryptographic session the durable object: the session survives total path loss, restarts, and dormancy, and re-anchors on a new path with fresh post-quantum key material. It is a November 2026 IETF draft, not a shipping product.

Is PQST a standard yet?

No. PQST is a set of three Internet-Drafts at revision -00, posted on 2 November 2026. The core draft proposes Standards Track work, the overview is Informational, and the cohort layer is Experimental.

Internet-Drafts are work in progress, valid for a maximum of six months, and the author is still seeking a working-group home for the core protocol.

How is PQST different from WireGuard?

WireGuard keeps a configured peer and replaces traffic keys by repeated handshakes, using classical public-key cryptography. PQST keeps the session itself — its identifier, authorization, and bindings — and re-anchors it with fresh post-quantum key material, using ML-KEM-1024 identities and no classical cryptography at all. WireGuard is shipping and deployed at scale; PQST is a three-day-old first draft.

What is the PQST cohort layer?

The cohort layer applies the session idea one level up: a group whose members' sessions move, sleep, recover, and re-key independently while the group's membership changes only on security events. One sequencer commits the membership, the policy, and a membership epoch together with that epoch's key. This version specifies only the control plane; there is no group data plane yet.

Does PQST replace TLS?

No. TLS 1.3 is a secure channel that rides on a reliable, in-order data stream; PQST is a datagram transport that runs directly over UDP. They work at different layers.

A tunnel could one day carry TLS inside it, but PQST does not replace the channel — it replaces the idea that a tunnel must die with its connection.