Post Quantum Shell (PQS)

Executive Summary

Post-quantum secure remote access designed as a replacement-class successor to SSH

PQS is a control-plane secure access protocol built for remote administration, orchestration, and interactive shell sessions in environments that cannot tolerate a future break in classical public-key assumptions. The design adopts a server-authenticated Simplex model: clients pin a server verification record, authenticate a signed ephemeral encapsulation key, derive directional traffic keys from the resulting shared secret, and then transition into an authenticated encrypted session channel.

Within the QRCS stack, PQS should be understood as a direct SSH replacement rather than a generic tunnel profile. Its replacement value comes from three structural decisions: elimination of runtime negotiation, concentration of trust in a pinned server identity instead of mutual key sprawl, and a compact packet/state model that binds sequencing, payload size, and UTC freshness directly into the authenticated transcript.

Very High relative value Role: Secure remote access and control-plane protocol Primary buyers: Cloud, finance, defense, government, enterprise infrastructure

Protocol At A Glance

Trust model Server-authenticated one-way trust

The client pins (cfg, kid, pvk, expiration) and authenticates only the server at key exchange time, leaving higher-layer user authentication to the encrypted channel.

Handshake 4-message Simplex AKE

Connect Request and Exchange Request from the client are matched by Connect Response and Exchange Response from the server, followed by channel activation.

Packet model 21-byte authenticated header

Every packet binds flag, sequence number, payload length, and UTC timestamp into acceptance logic and authenticated data processing.

Runtime profile Small per-session state

The specification positions the server as capable of maintaining uniquely keyed client tunnels with less than four kilobytes of session state per connection.

Source Repository

The implementation repository for PQS, positioned within the wider QRCS protocol family and suitable for diligence review of code, interfaces, and integration approach.

Open Repository

Formal Analysis

Provable treatment of the Simplex server-only authenticated key-exchange model, including authentication, session-key indistinguishability, forward secrecy, and replay-resistant integrity.

Open Formal Analysis

Technical Specification

Engineering description of protocol strings, key structures, packet formats, handshake sequencing, error states, keep-alive behavior, and the PQS communications stream.

Open Technical Specification

Strategic Positioning

PQS replaces SSH by removing negotiation complexity and recentering trust on a single authenticated server identity

The core design problem is not merely that SSH uses classical cryptography. It is that SSH also carries a long history of negotiated profiles, fallback behavior, mutual key administration, and extension-driven complexity that is difficult to audit consistently across implementations.

Why the replacement case is structurally strong

PQS fixes the cryptographic posture in advance, authenticates the server through a pinned post-quantum verification record, and derives transport state from a transcript-bound KEM exchange rather than from a large compatibility-oriented negotiation surface. That gives the protocol a smaller and more analyzable attack surface than legacy secure shell deployments.

Dimension	Legacy SSH	PQS
Cryptographic basis	Classical RSA / ECC heritage	Native post-quantum KEM and signatures
Trust posture	Mutual host-key management	Server-authenticated one-way trust
Negotiation	Extensive algorithm and option surface	Fixed configuration string
Replay controls	Protocol-dependent	Sequence and UTC time bound into header validation
Implementation scope	Large and historically layered	Deliberately compact secure-shell profile

High-level technical rationale

PQS begins from a narrower operational assumption than SSH: the client already knows which server it intends to trust. That assumption allows the protocol to pin the verification key and configuration metadata in advance, hash them into a session cookie, and then verify that the server’s ephemeral encapsulation key is authentic before any shared secret is accepted.

Session establishment is tied to cfg, kid, and pvk, not to runtime suite discovery.
The server’s long-term key signs only the Connect Response hash over the serialized header and ephemeral public key.
The data phase inherits integrity from both header validation and AEAD binding of the full packet header.
Ephemeral key material is erased immediately after derivation, ensuring forward secrecy across session boundaries.
All packet processing is length-validated and structure-bound, preventing malformed message acceptance at every stage.
Key derivation is performed through deterministic SHAKE-based expansion, binding session keys to transcript context.
Transport state is strictly directional, with independent send and receive cipher instances to prevent state collision.

From an acquisition standpoint, PQS is best understood as a replacement-class post-quantum control-plane access protocol for infrastructure where the cost of leaving SSH-era assumptions in place is strategic rather than merely technical.

Protocol Architecture

The protocol separates pinned server identity, ephemeral key exchange, and directional traffic state

The formal model describes PQS as a Simplex server-only authenticated key-exchange protocol. The client retains a pinned verification record, while the server holds the corresponding signing key and generates a fresh ephemeral KEM key pair for each session.

Client Pin

The client anchors trust in a local record containing the configuration identifier, key identifier, server verification key, and expiration. This state is selected before the handshake begins.

Record	(cfg, kid, pvk, expiration)
Purpose	Server authentication and configuration binding

Server Keyring

The server stores a long-term signing key pair and a keyring indexed by kid. Each keyring entry carries the same configuration and expiration semantics expected by the client.

Keying	ML-DSA / Dilithium or equivalent signature profile
Use	Signs only the Connect Response hash

Ephemeral KEM

For each session, the server generates a fresh encapsulation key pair. The client verifies the signed public key, encapsulates a shared secret, and transmits only the ciphertext.

Profiles	Kyber / ML-KEM or McEliece-class encapsulation
Effect	Fresh per-session secret and client forward secrecy

Directional Channel

The shared secret and session cookie feed a SHAKE/cSHAKE expansion that yields separate send and receive keys and nonces, which are loaded into independent cipher states.

State	Send cipher, receive cipher, tx/rx counters
Mode	RCS by portfolio positioning; formal model also treats AES-GCM

Cryptographic Construction

Session cookie binding, signed ephemeral KEM, and header-bound authenticated encryption define the core mechanics

The specification and formal paper are aligned on the main construction: bind server identity and configuration into a cookie, authenticate the ephemeral KEM public key, derive directional keys from the KEM shared secret plus cookie, and require every data packet to pass both protocol-state validation and authenticated decryption.

Handshake abstraction

Security Protocol Notation
sch ← H(cfg ∥ kid ∥ pvk)
Server: (pk, sk) ← KEM.KeyGen()
h ← SHA3(hdr₂ ∥ pk), σ ← SIG.Sign(ssk, h)
Client: verify SIG.Verify(pvk, h, σ)
(cpt, sec) ← KEM.Encaps(pk)
prnd ← cSHAKE(sec, sch, outlen)
prnd = k₁ ∥ n₁ ∥ k₂ ∥ n₂

The client uses (k₁, n₁) for send and (k₂, n₂) for receive; the server uses the reverse assignment, ensuring that no key/nonce pair is reused in both directions. This directional separation eliminates the possibility of keystream reuse under bidirectional traffic and preserves the independence of encryption domains across the channel. It also simplifies state validation, as each side can enforce strict monotonic sequencing within its transmit and receive contexts without ambiguity.

Primitive and state inventory

Signature	Dilithium / ML-DSA in the formal model, with specification allowance for SPHINCS+ profiles.
KEM	ML-KEM / Kyber in the formal model, with specification support for McEliece profiles in the protocol string.
Hash / XOF	SHA3-256 binds the session cookie and signed response hash; SHAKE or cSHAKE expands the shared secret into directional channel state.
Channel AEAD	RCS is the QRCS-positioned transport cipher; the formal treatment also models an AES-GCM instantiation with the same header binding.
Reserved evolution	Connection state includes ratchet-related material for optional asymmetric or symmetric rekeying during longer-lived sessions.

Handshake and Packet Model

A four-message Simplex flow and a compact header keep session establishment narrow and explicit

The protocol’s operational surface is intentionally small. The client sends only a connect request and a KEM ciphertext, while the server responds with an authenticated ephemeral key and a final exchange confirmation. After that, communication proceeds entirely under the derived channel state.

Handshake stages

Message	Function
Connect Request	Client sends kid ∥ cfg under a fresh header and begins the handshake state.
Connect Response	Server validates key identity and configuration, computes sch, creates an ephemeral KEM key pair, and signs SHA3(hdr₂ ∥ pk).
Exchange Request	Client verifies the signed response, encapsulates the shared secret, initializes directional channel keys locally, and sends the ciphertext.
Exchange Response	Server decapsulates, initializes the matching cipher states, returns an empty confirmation packet, and the session becomes active.

Common packet envelope

Field	Size	Purpose
Packet flag	1 byte	Handshake stage, encrypted message, keep-alive, ratchet, or error class
Packet sequence	8 bytes	Ordered acceptance and replay control
Message size	4 bytes	Expected payload-length validation before processing
UTC time	8 bytes	Freshness check against the allowed acceptance window

The same fixed header format is used for handshake traffic and the encrypted communications stream. The receiver validates flag, sequence, size, and timestamp before it accepts the packet into the current protocol state.

Security Model

The formal treatment proves server authentication, key indistinguishability, forward secrecy for the client, and authenticated replay-resistant transport

The formal paper models PQS in a Simplex server-only authenticated key-exchange framework. This matters because the trust asymmetry is not incidental. It is the intended operating model, and the reductions are written to match it exactly.

Properties proved or reduced

Server authentication reduces to EUF-CMA security of ML-DSA over the signed Connect Response hash.
Session-key indistinguishability reduces to IND-CCA security of the underlying KEM combined with pseudo-randomness of cSHAKE.
Forward secrecy for the client follows from erasure of the server’s ephemeral KEM secret key after decapsulation.
Channel confidentiality and integrity reduce to IND-CCA and INT-CTXT security of the AEAD instantiation.
Replay and reordering resistance follow from authenticated header binding together with sequence-window and UTC freshness checks.

Why header binding matters

In PQS, the full serialized header becomes associated data for the active channel. That means flag, sequence number, message length, and timestamp are not passive transport metadata. They are part of the cryptographic acceptance predicate itself. A packet can only be accepted if the protocol state allows the flag, the sequence number is valid, the timestamp is inside the freshness window, the declared length matches the body, and authenticated decryption succeeds.

This is a materially stronger discipline than treating replay and ordering as only transport-layer concerns. It turns the packet header into a first-class security object and helps keep the data plane narrow, deterministic, and auditable.

Operational profile

Designed for dense remote-access workloads with predictable behavior under fixed configuration

PQS is aimed at the secure administration layer of infrastructure rather than at generalized internet interoperability. The absence of runtime negotiation means that connection establishment cost is determined mainly by one authenticated KEM exchange and deterministic key expansion, not by version fallback or suite discovery. The specification positions the server as a multi-threaded platform capable of maintaining very large numbers of concurrent client tunnels while keeping per-session state compact. That matters because control-plane systems frequently experience the inverse of bulk-transport conditions: many simultaneous sessions, modest payload sizes, strict identity requirements, and high sensitivity to implementation complexity.

Once the handshake completes, the channel is symmetric and stateful. Each direction maintains its own cipher context and sequence progression, while keep-alive, error, and ratchet signaling remain inside the same constrained packet model. The result is a profile well suited to high-density server fleets, orchestration layers, remote management fabrics, and administrative access paths that need a smaller and more durable cryptographic base than SSH can offer.

Deployment fit

PQS is aligned with operators that need long-lived, high-assurance remote access in post-quantum planning horizons: cloud and hosting platforms, fintech and exchange infrastructure, government systems, defense environments, regulated industrial deployments, and embedded administrative planes.

Role in stack	Application-facing secure remote access and control-plane protocol
Primary buyers	Cloud providers, financial institutions, defense contractors, government, enterprise infrastructure operators
Replacement case	SSH and legacy secure shell control channels with classical or hybrid negotiation complexity