Quantum Secure Tunneling Protocol (QSTP)
Deterministic post-quantum channel establishment with root-anchored authentication and transcript-bound session state
QSTP is a replacement-class secure channel protocol for controlled environments that do not benefit from the negotiation surface, extension complexity, and legacy compatibility burden of TLS-derived designs. It combines a root-signed server certificate model, an ephemeral post-quantum KEM exchange, a signed transcript-bound ephemeral encapsulation key, and symmetric packet protection into a narrow state machine whose purpose is clarity, auditability, and constrained attack surface.
Within the QRCS stack, QSTP occupies the role of a general-purpose deterministic secure transport. It is intentionally lighter than DKTP’s dual-entropy ratcheted tunnel model, but materially more opinionated than general internet protocols: the suite is fixed, the handshake is linear, the server is authenticated before key establishment proceeds, and the channel activates only after explicit transcript confirmation proves both peers derived identical session state.
The client validates the server certificate against a trusted root key before any encapsulated secret is accepted, and no client-side long-term authentication key is required.
The exchange consists of ConnectRequest, ConnectResponse, ExchangeRequest, and ExchangeResponse, followed by a local EstablishVerify transcript comparison.
Session keys and initial nonces are derived from the KEM shared secret and the final transcript hash, binding the entire exchange into the channel state.
A one-byte flag, four-byte length, eight-byte sequence value, and eight-byte timestamp are bound as associated data to the RCS channel.
Executive Summary
The strategic and acquisition-oriented summary of QSTP, positioned within the broader QRCS transport and infrastructure stack.
Open Executive SummaryFormal Analysis
Game-based treatment of authenticated key exchange, channel confidentiality, replay restrictions, transcript consistency, and comparative design tradeoffs against TLS 1.3 and WireGuard.
Open Formal AnalysisTechnical Specification
Engineering-level description of the root module, client and server roles, KEM exchange, packet structures, sequence validation, timestamps, and channel establishment semantics.
Open Technical SpecificationQSTP is a controlled secure channel, not a negotiation-heavy transport framework
The protocol was designed for environments where both peers operate under aligned assumptions and where a small, deterministic state machine is more valuable than broad interoperability features. Its design rationale is therefore rooted in the removal of optional branches, runtime suite discovery, version fallback, and other negotiation surfaces that complicate both implementation and formal analysis.
Why the model is materially different
QSTP fixes the cryptographic posture in advance, authenticates the server before shared secret use, commits every handshake stage into a running transcript hash, and requires explicit key confirmation before entering the encrypted channel. The result is a transport profile that is more suitable for managed, high-assurance deployments than general-purpose internet interoperability frameworks.
| Dimension | Negotiated stacks | QSTP |
|---|---|---|
| Suite selection | Runtime negotiation and policy handling | Fixed configuration known in advance |
| Handshake shape | Multiple branches and extension paths | Single linear exchange path |
| Downgrade surface | Must be defended explicitly | Minimized by eliminating negotiation |
| Authentication mode | Often flexible or multi-mode | Root-anchored unilateral server authentication |
| Activation condition | Implementation dependent state transition | Explicit transcript-hash confirmation |
High-level technical rationale
The central design choice is that predictable behavior is itself a security control. By constraining the exchange to one certificate model, one transcript flow, one KDF binding rule, and one packet-acceptance interpretation at each stage, QSTP reduces the number of states an implementation must defend and the number of assumptions a reviewer must reconstruct from code.
- Certificate and configuration state are authenticated before key establishment proceeds.
- The signed ephemeral KEM key is bound to both the packet header and the current transcript state.
- The final transcript hash carried by the server functions as an explicit key-confirmation gate.
- Sequence values and UTC timestamps are validated at each stage to prevent replay or out-of-order state transitions.
- Header fields are incorporated as associated data, ensuring that metadata tampering results in immediate authentication failure.
- Directional keys and nonces are derived independently, preventing cross-direction reuse and preserving strict channel separation.
Root, server, client, core, and KEX engine form a narrow implementation model
The formal engineering description presents QSTP as a small set of cooperating modules with minimal coupling. Each module has a sharply delimited responsibility, which is one reason the protocol remains comparatively tractable to audit and reason about.
Root
The root module provides the static trust anchor. It exports the root certificate, the root public verification key, and the validation logic used by clients to authenticate server certificates before exchange processing begins.
| Role | Trust anchor and certificate validation basis |
|---|---|
| Mode | Self-signed by default, externally signed mode optional |
Server
The server module validates the inbound request, generates a fresh ephemeral KEM key pair, signs the transcript-bound ephemeral key hash, decapsulates the client ciphertext, derives channel keys, and emits explicit key confirmation.
| Role | Authenticated responder and decapsulation endpoint |
|---|---|
| State | Long-term signature key plus per-session ephemeral KEM secret |
Client
The client module initiates the exchange, validates the server certificate and signed ephemeral KEM key, encapsulates the shared secret, derives local channel state, and performs the final transcript equality check before activation.
| Role | Initiator and verifier |
|---|---|
| Model | No client certificate or client long-term key required |
Core + KEX
The QSTP core and KEX engine define packet formatting, transcript evolution, session-cookie handling, key derivation, header validation, RCS associated-data processing, and deterministic encapsulation and decapsulation flow.
| Role | State machine, key schedule, and channel logic |
|---|---|
| Property | Linear composition with minimal module coupling |
Root-signed server identity, signed ephemeral KEM binding, and transcript-derived directional channels
QSTP composes four principal cryptographic elements: a post-quantum KEM for ephemeral shared-secret establishment, a post-quantum signature scheme for server authentication, a cSHAKE-based key derivation process, and the RCS authenticated encryption channel for data transport.
Handshake abstraction
The fixed exchange can be summarized as a transcript-bound authenticated KEM flow in which the server signs the ephemeral encapsulation key hash and the client verifies that the final transcript state exactly matches the server’s view before entering the channel phase.
C → S : serial ∥ cfg
sch₀ ← H(cfg ∥ serial ∥ pvk)
S → C : SIG(H(phdr ∥ sch₀ ∥ pkkem)) ∥ pkkem
sch₁ ← H(sch₀ ∥ H(phdr ∥ sch₀ ∥ pkkem))
C → S : cpt, sec ← KEM.Enc(pkkem)
sch₂ ← H(sch₁ ∥ cpt), prnd ← cSHAKE(sec, sch₂)
S → C : sch₂
C : ConstantTimeEqual(sch₂, sch₂local)
Primitive and state inventory
| KEM layer | Kyber / ML-KEM or McEliece-class post-quantum encapsulation profiles, used with fresh ephemeral server key generation per session. |
|---|---|
| Signature layer | ML-DSA / Dilithium or SLH-DSA / SPHINCS+-class signing for server certificate issuance and signed ephemeral key binding. |
| KDF | cSHAKE expansion of the KEM shared secret under sch₂, partitioned into client→server and server→client keys and initial nonces. |
| Channel AEAD | RCS authenticated encryption with header fields incorporated as associated data; AES-256-GCM is also described as a selectable option in the repository documentation. |
| Trust assumption | Authenticity of the root key distribution and validity of the server certificate chain. |
Strict stage validation is one of the protocol’s central security defenses
The formal paper and portfolio chapter converge on the same point: QSTP’s small attack surface is not merely a consequence of using strong primitives, but of enforcing a narrow interpretation of valid session state throughout both handshake and channel operation.
Stage progression and acceptance rules
| Stage | Security function |
|---|---|
| ConnectRequest | Commits to the target server certificate serial and fixed protocol configuration before any asymmetric exchange begins. |
| ConnectResponse | Returns the signed ephemeral KEM public key, which is verified against the trusted server identity and current transcript state. |
| ExchangeRequest | Commits the client ciphertext into the transcript and derives directional channel state from the shared secret and sch₂. |
| ExchangeResponse | Carries the final transcript hash as explicit key confirmation and transitions the server into the established state. |
| EstablishVerify | Forces a constant-time transcript comparison on the client before any protected application data is accepted. |
Why the fixed state machine matters
Every inbound packet is validated for the expected flag, the expected message size for that stage, the exact or strictly monotone sequence behavior required by the state, and a timestamp freshness bound before any successful decrypt-and-release path is permitted. This means that replay filtering and state sanity checks begin before the channel’s ciphertext authentication result is allowed to influence application behavior.
Once established, the channel remains conservative: it provides one-way server authentication, forward secrecy through ephemeral KEM use, and an optional symmetric ratchet, but it does not broaden into a more flexible negotiation framework after activation. That design discipline is the practical meaning of QSTP’s narrow attack surface.
Operationally, this produces a transport that behaves as a strict state machine rather than a negotiable session. Each transition is gated by validated structure, authenticated transcript continuity, and bounded freshness, so the channel does not admit ambiguous intermediate states that can be exploited for downgrade, replay, or transcript-confusion attacks.
Compact authenticated headers make transport metadata part of the cryptographic validity condition
After establishment, QSTP transmits application data under a compact fixed-format header whose fields are bound into the AEAD processing as associated data. Metadata tampering therefore becomes an authentication failure rather than a separate parsing problem.
Header envelope
| Field | Size | Function |
|---|---|---|
| Flag | 1 byte | Logical packet type or control signal |
| Length | 4 bytes | Authenticated payload-length context |
| Sequence | 8 bytes | Strict ordering and replay control |
| Timestamp | 8 bytes | Freshness check relative to the configured acceptance window |
Acceptance logic
On receipt, the implementation first validates the sequence number and freshness window, confirms that the header structure and lengths are consistent with the current channel state, and only then invokes decryption with the serialized header bound as associated data. Any sequence anomaly, stale timestamp, malformed header, or authentication-tag failure causes immediate rejection without plaintext release.
Header = ⟨flag, mlen, seq, ts⟩
C ← RCS.Enc(k, n, Header, P)
Accept only if:
seq = expected next value
|ts − now| ≤ Δ
RCS.Dec(k, n, Header, C) ≠ ⊥
Formal treatment reduces QSTP to the security of its component primitives
The analysis models QSTP as a composition of a post-quantum KEM, a post-quantum signature scheme, a hash-based KDF in the random-oracle style model, and an authenticated encryption channel. Security goals are expressed as explicit authenticated key exchange and channel-security experiments.
Security properties proved or reduced in the formal model
- Server authentication reduces to certificate validation and EUF-CMA security of the signature scheme.
- Session-key indistinguishability reduces to the IND-CCA security of the post-quantum KEM and the pseudo-randomness of the KDF construction.
- Channel confidentiality and integrity reduce to the AEAD security of the RCS transport layer.
- Replay resistance follows from authenticated sequence values, timestamp freshness checks, and transcript consistency requirements.
- Forward secrecy follows from ephemeral per-session KEM keys and destruction of ephemeral material after use.
Adversarial and deployment considerations
The formal paper also evaluates denial-of-service considerations created by post-quantum key exchange, the consequences of choosing unilateral rather than mutual authentication, and the comparative state-machine simplicity of QSTP relative to TLS 1.3 and WireGuard. The design goal is not maximum generality, but a transport whose security claims remain closely aligned with its code path.
This matters in practice because a deterministic handshake is easier to verify, easier to constrain in production policy, and easier to compare against implementation behavior. The narrow model is therefore not just a cryptographic choice but an assurance strategy.
High assurance transport for controlled deployments
QSTP is intended for environments where peers are known in advance, the cryptographic suite can be fixed at deployment time, and the secure channel is expected to behave identically from session to session. This includes service-to-service communication in managed systems, secure internal infrastructure links, high-assurance embedded deployments, and application environments that want a secure channel without inheriting the full negotiation and extension machinery of TLS. The implementation model reflects that intent: the codebase is kept small, state progression is linear, and the protocol’s verification logic is concentrated in a limited set of well-defined checks. This determinism simplifies audit, testing, and formal reasoning because every valid session follows the same bounded execution path. It also reduces configuration risk by eliminating runtime suite selection and extension negotiation variability.
The repository documentation also positions QSTP as a performant operational system rather than a purely theoretical construction. The server is described as a multi-threaded platform with per-client connection state under four kilobytes, permitting very large concurrent tunnel populations while still preserving per-session ephemeral KEM isolation and transcript-bound channel derivation. This allows high connection density without introducing shared cryptographic state across sessions. It further ensures that scaling the service does not dilute forward secrecy or increase cross-session attack surface.
Deployment fit
QSTP is particularly well aligned with managed enterprise channels, secure infrastructure backplanes, embedded or appliance deployments, financial and industrial service links, government or defense environments, and any controlled system that wants post-quantum channel establishment without general internet protocol complexity.
| Role in stack | General-purpose deterministic secure transport |
|---|---|
| Operational fit | Known-peer environments with fixed cryptographic posture |
| Why it matters | Reduces implementation ambiguity, negotiation risk, and protocol-management burden |