Quantum Secure Messaging Protocol (QSMP)

Executive Summary

Deterministic post-quantum transport with unified one-way and mutual-authentication channel models

QSMP is a replacement-class secure transport protocol for environments that need authenticated, encrypted, and integrity-bound communications without negotiation-era ambiguity. It combines post-quantum key encapsulation, signature-authenticated handshake stages, transcript-bound derivation, and an RCS-based authenticated data channel into a single transport model spanning both client-server and peer-to-peer trust topologies.

Within the QRCS stack, QSMP functions as the primary secure messaging and transport layer. Its strategic value derives from eliminating runtime parameter negotiation, preserving a fixed cryptographic posture across deployments, and offering two coordinated modes, SIMPLEX and DUPLEX, without fragmenting packet structure or operational semantics. From an acquisition perspective, it is best understood as a high-assurance substitute for legacy TLS-, SSH-, and IPSec-class channels in systems where long-term confidentiality, deterministic behavior, and clean protocol analysis matter more than broad backward compatibility.

Very High relative value Role: Post-quantum secure messaging and transport layer Primary buyers: Government, finance, telecom, cloud, industrial infrastructure
Protocol At A Glance
Operating modes QSMS + QSMD

The design now separates into Simplex and Duplex variants that preserve common framing and primitive discipline while addressing one-way and mutual-authentication trust models.

Configuration model Fixed, parameter-bound

Cipher families and security classes are carried by configuration identifiers rather than negotiated at runtime, materially reducing downgrade surface.

Packet model 21-byte authenticated header

Flag, sequence, payload length, and UTC time are compactly encoded and then bound into authenticated encryption as associated data.

Channel model Directional AEAD state

Session establishment produces independent transmit and receive keys and nonces, with optional ratcheting for continued state evolution after setup.

Executive Summary

The strategic and acquisition-oriented summary of QSMP, positioned within the QRCS transport and infrastructure stack, for secure messaging and identity-bound communications systems.

Open Executive Summary

Formal Analysis

Game-based treatment covering Simplex and Duplex authentication, key indistinguishability, replay and reordering resistance, and authenticated-channel security.

Open Formal Analysis

Technical Specification

Engineering-level description of packet framing, key states, handshake sequencing, configuration identifiers, error handling, and API structure for QSMS and QSMD.

Open Technical Specification
Strategic Positioning

QSMP is built as a deterministic replacement for negotiation-heavy secure-channel stacks

The protocol was designed against a specific class of weaknesses in legacy transport systems: runtime suite negotiation, layered compatibility behavior, and inconsistent trust semantics across otherwise similar channels. QSMP removes these variables by fixing the cryptographic posture, binding it into the transcript, and preserving the same data-channel semantics across both one-way and mutual-authentication modes.

Why the model is materially different

QSMP does not approach post-quantum migration as an extension layer. It begins from a native post-quantum transport construction in which handshake messages, encapsulation keys, transcript hashes, and channel states are all part of one bounded design. That makes the protocol easier to validate, easier to reason about formally, and less exposed to versioning and downgrade ambiguity than traditional channel stacks.

Dimension Legacy stacks QSMP
Parameter model Negotiated at runtime Fixed configuration string
PQ posture Transitional or hybrid Native post-quantum
Trust topology Separate protocol families Unified SIMPLEX / DUPLEX framework
Downgrade exposure Residual Structural resistance
Session isolation Variable Ephemeral establishment + AEAD state separation

High-level technical rationale

The protocol combines a post-quantum KEM, a signature layer, SHA3-family transcript handling, and an RCS authenticated channel so that every accepted packet is tied to an explicit cryptographic context. In SIMPLEX, the client authenticates the server and derives a fresh duplexed channel in a low-latency pattern. In DUPLEX, both peers contribute authenticated ephemeral material and confirm that they arrived at the same session state before the tunnel is considered live.

This matters operationally because it gives implementers one disciplined transport substrate for anonymous-client service models, mutual-host peering, messaging systems, VPN-style channels, and higher-level QRCS protocols without reopening the core questions of key exchange structure, packet validation, or header authentication for every deployment.

From a system design perspective, QSMP reduces protocol surface area by collapsing authentication, key establishment, and transport protection into a single transcript-bound construction. This allows higher-layer messaging and service logic to inherit consistent security guarantees without reimplementing handshake logic, while maintaining clear auditability and deterministic behavior across deployments.

From an acquisition standpoint, QSMP should be read as a core transport primitive rather than a narrow application protocol. It is the communication backbone that other QRCS systems can inherit when they need deterministic secure transport with native post-quantum assumptions.
Architecture and Operation

Two handshake constructions share one packet discipline and one channel model

QSMP defines common framing, configuration identifiers, key structures, and authenticated packet handling across both modes. The differentiation lies in how trust is established and how many independently generated shared secrets enter the key schedule.

Simplex channel establishment

Simplex is the one-way-trust variant. The client already possesses, or has externally provisioned, the server verification key and corresponding key identity. The server returns a signed ephemeral encapsulation key; the client verifies the signature and header binding, encapsulates a shared secret, and derives independent send and receive keys and nonces from that secret and the transcript state.

The engineering goal is low-latency authenticated transport without client long-term identity requirements. The specification treats this as a two-round-trip path with compact per-connection state and immediate transition to an established encrypted stream once transcript confirmation succeeds.

Duplex channel establishment

Duplex extends the same framing into a bilateral-authentication model. Both peers hold long-term signing keys and stored verification keys for the other side. Each endpoint signs its ephemeral contribution, each endpoint derives KEM secrets involving peer ephemeral material, and the final channel state depends on two independent shared secrets and a rolling transcript hash.

That construction prevents unilateral control over session state and yields a higher-assurance transport profile for peer-to-peer or host-to-host secure channels. The establish stage then encrypts transcript confirmation values over the newly created channel so that both parties prove agreement on the same exchange history before accepting traffic.

Handshake skeleton

Session flow summary SIMPLEX connect_request → connect_response → exchange_request → exchange_response / verify DUPLEX connect_request → connect_response → exchange_request → exchange_response → establish_request → establish_response → establish_verify

In both paths, accepted messages are validated against the expected flag, exact message size for that stage, sequence value, and time window before any successful session transition is permitted. This enforces a single valid interpretation of protocol state at each step, eliminating ambiguity in message ordering and processing. As a result, replay attempts, malformed inputs, and out-of-context packets are rejected prior to any cryptographic state advancement.

Core session elements

ConfigurationFixed string binding the selected primitive set and security profile
IdentityKey identifier used to select and bind long-term verification material
TranscriptRolling SHA3-based state extended with authenticated handshake material
Channel stateIndependent transmit and receive cipher contexts plus optional ratchet state
Construction Details

Post-quantum encapsulation, transcript-bound derivation, and authenticated header processing

The handshake is only one part of QSMP’s security posture. The protocol derives its practical strength from how cryptographic inputs are combined and how aggressively packet structure is authenticated after establishment.

Primitive roles in the design

Component Role
KEM secret(s) Fresh entropy for session establishment, with one secret in Simplex and two bilateral contributions in Duplex
SHA3 / cSHAKE / KMAC Transcript hashing, key expansion, domain separation, and state derivation
RCS AEAD Authenticated encryption of application traffic with header binding as associated data
Signature scheme Authentication of ephemeral encapsulation material and transcript-linked handshake values
The current specification highlights Dilithium-Kyber, Dilithium-McEliece, and SPHINCS+-McEliece style pairings, with parameter classes mapped to low, medium, and high post-quantum security targets.

Packet and state discipline

QSMP packets carry a compact 21-byte header consisting of a one-byte flag, eight-byte sequence value, four-byte payload length, and eight-byte UTC timestamp. The serialized header is treated as associated data for authenticated encryption, so metadata tampering becomes an authentication failure rather than a secondary parsing issue.

That compact framing is matched by a deliberately small operational state: transmit and receive sequence counters, directional cipher states, expiration values, session identifiers, and an optional ratchet value. The protocol therefore remains suitable for high-throughput or high-concurrency deployments without surrendering strict packet validation.

This is also why QSMP can operate over multiple transport substrates. TCP is used in the example implementation, but the design is intentionally transport-agnostic at the cryptographic layer and can be mapped onto UDP, QUIC, or custom stack environments without altering the packet semantics.

In practice, this separation of cryptographic semantics from transport behavior allows QSMP to maintain identical security guarantees across deployment environments, from persistent service connections to intermittent or lossy network paths. It also simplifies integration into existing systems, since transport adaptation does not require redesign of the handshake, packet validation rules, or authenticated data model.

Operational Profile

Low-latency establishment, bounded state, and clean integration into larger systems

QSMP was written to be a building block, not an isolated academic handshake. The specification emphasizes that the core exchange, message authentication, and encryption functions are mandatory protocol components and that the API is intended to expose these behaviors through a relatively compact client/server interface.

Performance and engineering posture

Handshake cost depends on the chosen KEM and signature family, but the protocol avoids the variability common to fallback-oriented systems. Simplex is explicitly optimized for environments where many authenticated client-to-server channels must be created quickly, while Duplex is aimed at higher-assurance persistent peering where mutual authentication and explicit transcript confirmation justify the extra stages.

Once established, the transport path is dominated by RCS authenticated encryption and header validation rather than further asymmetric work. Session memory remains comparatively low, and the protocol aligns with the broader QRCS implementation model of deterministic execution, explicit validation, and MISRA-oriented coding discipline.

Integration value inside the QRCS stack

QSMP is described in the portfolio and specification as a powerful building block for constructing larger protocol systems. It can supply the secure transport substrate beneath application protocols, relay systems, administrative channels, and control-plane services without requiring those systems to redesign handshake semantics or authenticated packet handling from first principles.

This is strategically important because it lets QRCS stack components share one disciplined transport model. Higher-level systems can add access control, routing logic, or domain coordination while inheriting fixed configuration, transcript-bound authentication, and authenticated directional channel state from QSMP itself.

Security Model

Formal treatment covers authentication, key indistinguishability, forward secrecy, and authenticated-channel integrity

The formal paper models a multi-session active adversary with transcript visibility, adaptive interference, and selected compromise capabilities. Security results are framed through explicit channel-establishment goals rather than informal protocol claims.

Security properties proved or reduced in the model

  • Simplex unilateral authentication reduces to the unforgeability of the server signature over authenticated ephemeral material.
  • Duplex mutual authentication reduces to the signature security of both participants and to correct transcript confirmation.
  • Session-key indistinguishability reduces to the IND-CCA security of the selected post-quantum KEM and the pseudo-random behavior of the derivation path.
  • Channel confidentiality and integrity reduce to the AEAD properties of RCS when the serialized packet header is included as associated data.
  • Replay and reordering resistance are enforced by authenticated sequence values and timestamp windows, making accepted out-of-order traffic equivalent to a forgery success.

Security boundaries and implementation implications

The formal results assume correct key provisioning, bounded clock drift, monotonic sequence enforcement, sound entropy, and constant-time behavior of the cryptographic implementation. Those assumptions are not decorative. The formal analysis is explicit that failures in randomness, time synchronization, state transition enforcement, or external key distribution lie outside the proof boundary.

QSMP therefore pairs well with environments that can maintain disciplined operational controls: audited key distribution, strict session teardown on failure, conservative rate limiting, and deterministic validation of every packet before state advancement. In those environments, the protocol’s security claims map cleanly to its implementation behavior.

Deployment profile

QSMP is aligned with environments that need analyzable transport, not negotiation flexibility

QSMP is particularly well suited to critical infrastructure, financial systems, defense communications, cloud backbone services, telecom control paths, distributed control environments, and embedded or edge systems that still require formally understandable secure transport. Its fixed configuration model helps operators maintain a consistent security posture across mixed deployments rather than inheriting the policy sprawl common to negotiation-centric channel stacks. The protocol can operate as a direct secure-messaging substrate, as a deterministic VPN-class tunnel core, or as the transport layer inside larger QRCS systems that need authenticated and replay-resistant packet exchange.

From an implementation standpoint, the design is restrained and auditable. Compact packet headers, low session-state requirements, stage-specific message-size checks, explicit expiration handling, and immediate teardown on verification failure all contribute to a transport model that is easier to review and easier to defend over long maintenance horizons than larger legacy secure-channel frameworks.

Deployment fit

QSMP is positioned in the portfolio as the high-assurance communication backbone that complements authentication systems such as SIAP and symmetric tunneling systems such as SATP while providing the post-quantum transport layer on which additional protocols can be built.

Role in stackPost-quantum secure messaging and transport layer
Primary buyersGovernment and defense agencies, financial institutions, telecom providers, cloud infrastructure vendors, industrial and critical infrastructure operators
Replacement caseTLS-, SSH-, and IPSec-class secure channels in deterministic or high-assurance environments