Dual Key Tunneling Protocol (DKTP)
Dual-entropy secure tunneling with transcript-bound establishment and evolving directional state
DKTP is a replacement-class secure channel protocol for long-lived, mutually authenticated tunnels. Its distinguishing property is that each tunnel direction is derived from two independent entropy domains: a post-quantum KEM shared secret and a persisted directional pre-shared secret. Those inputs are fused through a domain-separated Keccak-based key schedule to produce independent transmit and receive channel keys, nonces, and evolving peering state.
Within the QRCS stack, DKTP occupies the role of a high-assurance tunneling and transport primitive for environments that cannot tolerate dependence on legacy PKI, single-source session derivation, or loosely governed secure-channel negotiation. The protocol combines signed handshake stages, a rolling transcript hash, explicit establishment confirmation, authenticated packet headers, and mandatory symmetric state advancement after each successful tunnel establishment.
Connect, exchange, and establish phases are completed only when both peers decrypt and compare the same rolling transcript hash under the new tunnel state.
Each direction derives its own tunnel key and nonce from a distinct shared secret and the opposing persisted pre-shared secret using cSHAKE-512 with channel labels.
Every encrypted packet binds flag, sequence number, payload length, and UTC timestamp as associated data for replay resistance and strict ordering.
After derivation, the opposing pre-shared secrets are advanced with fresh tunnel material, and an optional asymmetric ratchet can inject new public-key entropy mid-session.
Executive Summary
Strategic and acquisition-oriented synopsis positioning DKTP as the most complete expression of the QRCS secure-tunnel model.
Open Executive SummaryFormal Analysis
Specification-accurate formal treatment of the handshake, transcript binding, directional key schedule, replay defenses, forward secrecy, and ratchet security.
Open Formal AnalysisTechnical Specification
Engineering-level description of peering keys, packet formats, key exchange messages, tunnel activation, ratchet options, and deployment scenarios.
Open Technical SpecificationDKTP is designed to replace single-source, PKI-dependent tunnels with a directionally compartmented secure channel
The protocol was created as a direct response to three recurrent weaknesses in conventional tunnel designs: reliance on cryptographic assumptions threatened by quantum adversaries, dependence on live certificate infrastructures or negotiable trust models, and session derivation that collapses both directions of traffic into one negotiated state.
Why the model is materially different
DKTP supplements post-quantum authenticated key exchange with persisted directional symmetric secrets, then forces tunnel activation through encrypted transcript confirmation. The result is a transport primitive better suited to sovereign, segmented, or long-horizon deployments than PKI-heavy VPN or TLS tunnel profiles.
| Dimension | Conventional Tunnels | DKTP |
|---|---|---|
| Trust basis | Live PKI or certificate-chain dependency | Locally provisioned bonded peering keys |
| Entropy model | Primarily negotiated asymmetric session secret | KEM secret combined with directional PSK material |
| Channel separation | Often one negotiated schedule for both directions | Independent transmit and receive key derivation |
| Establishment rule | Handshake completion often implies activation | Activation only after transcript-hash confirmation |
| Lifecycle behavior | Limited symmetric state evolution | Mandatory PSK advancement and optional live asymmetric re-keying |
High-level technical rationale
The central DKTP proposition is that a secure tunnel should not depend on a single cryptographic event. The handshake therefore authenticates both peers, produces two directional shared secrets, binds every stage into a rolling 512-bit transcript hash, and confirms the final state only after the new tunnel ciphers can successfully carry that transcript value end to end.
- Directional separation constrains compromise propagation across send and receive paths.
- Persisted PSK advancement gives the tunnel a stronger long-term lifecycle than one-shot session derivation alone.
- Fixed configuration strings prevent suite drift and downgrade behavior by construction.
From an acquisition standpoint, DKTP is best understood as a replacement-class secure tunneling architecture, not as an incremental variant of TLS, SSH, or conventional VPN frameworks. It departs from classical secure channel designs by combining asymmetric authentication, pre-shared key tree material into a unified construction, rather than relying solely on certificate-driven negotiation and session key exchange.
This results in a fundamentally different trust and key establishment model, where multiple independent inputs contribute to session security and key lifecycle control. DKTP should therefore be evaluated not as an alternative implementation within existing transport standards, but as a next-generation secure channel primitive designed for environments requiring stronger post-quantum resilience and tighter control over authentication and trust boundaries.
Bonded peering keys, explicit handshake state, and directional tunnel state define the protocol core
The specification organizes DKTP around private peering structures and tightly scoped runtime state rather than around external certificate lookups or permissive negotiation. Each component exists to constrain a particular trust or compromise boundary.
Remote peer key
The remote peering key is a secret distributed structure containing the remote verification key, a 256-bit pre-shared secret, a 128-bit key identifier, the 384-bit configuration string, and expiration metadata.
| Role | Provisioned trust anchor for the remote peer |
|---|---|
| Check | Configuration and expiry must validate before connection |
Local peer key
The local peering key extends the same structure with the signing key and remote key identity linkage, so that the bonded pair can authenticate each stage of the exchange without external PKI services.
| Role | Local signing authority and paired-identity record |
|---|---|
| State | Single-use pairing tied to one remote host |
KEX state
Client and server key-exchange state store the rolling transcript hash, asymmetric encapsulation and decapsulation material, local and remote PSKs, verification keys, and the local shared secret retained for directional derivation.
| Role | Handshake memory and derivation workspace |
|---|---|
| Cycle | Erased after successful establishment |
Connection state
The active connection state holds transmit and receive cipher instances, sequence counters, exchange flags, and, when enabled, the asymmetric ratchet key material needed to re-key a live tunnel.
| Role | Operational tunnel state and packet sequencing |
|---|---|
| Mode | Optional live asymmetric ratchet support |
Signed handshake stages, transcript accumulation, and cSHAKE-based directional derivation drive tunnel establishment
The formal model treats DKTP as a fixed seven-message authenticated key-exchange and tunnel-establishment sequence. Post-quantum KEM and signature operations are concentrated in the handshake, after which the protocol transitions to directionally separated RCS-protected transport.
Handshake abstraction
The engineering description and formal paper align on a seven-message flow: Connect-Request, Connect-Response, Exchange-Request, Exchange-Response, Establish-Request, Establish-Response, and Establish-Verify. The key observation is that the tunnel is not considered established after KEM exchange alone.
M1: I → R : (kid, cfg, σ1), sch ← H(H(sph ∥ kid ∥ cfg))
M2: R → I : (ekR, σ2), sch ← H(sch ∥ H(sph ∥ ekR))
M3: I → R : (cpta, ekI, σ3), derive secl locally
M4: R → I : (cptb, σ4), derive secr and channel state
M5/M6/M7: encrypt, compare, and confirm sch under active tunnel ciphers
Primitive and state inventory
| KEM layer | Compile-time agility across Kyber / ML-KEM profiles and Classic McEliece-class options, with IND-CCA security assumed in the formal reductions. |
|---|---|
| Signature layer | Dilithium / ML-DSA and SPHINCS+-class profiles authenticate peer messages and ephemeral encapsulation material. |
| KDF | cSHAKE-512 with explicit channel labels DKTP:TXKEY:V1 and DKTP:RXKEY:V1 derives directional tunnel keys and nonces. |
| Symmetric layer | RCS authenticated encryption protects establishment confirmation and transport packets under independent transmit and receive instances. |
| Transcript state | A 512-bit rolling hash sch accumulates authenticated handshake material and is encrypted back through the new tunnel to prove shared state. |
Persisted directional PSKs, authenticated packet headers, and explicit sequencing define live tunnel behavior
DKTP is stateful in the strong sense. The active tunnel depends not only on long-term identity material, but on synchronized directional secrets, explicit exchange-stage validation, and monotonic packet processing rules.
Runtime state inventory
| Transcript hash | 512-bit rolling state initialized from the authenticated connect request and updated at each handshake stage. |
|---|---|
| Directional PSKs | Local and remote 256-bit pre-shared secrets that seed channel derivation and are immediately advanced after successful key schedule execution. |
| Cipher state | Independent transmit and receive RCS instances initialized from distinct tunnel keys and nonces. |
| Packet control | Eight-byte sequence numbers, four-byte payload lengths, exchange flags, and UTC timestamps are validated and authenticated. |
| Ratchet option | When enabled, live asymmetric re-keying retains encapsulation, decapsulation, signing, and verification material inside connection state. |
Why the dual-entropy lifecycle matters
The mandatory symmetric ratchet is not a cosmetic addition. After each directional derivation, the opposing persisted PSK is updated using newly derived tunnel material. This means the protocol does not merely create a fresh session; it advances the long-term peering state so that later tunnels do not begin from static historical inputs.
The optional asymmetric ratchet extends this design into live operation. A tunnel can carry a freshly generated signed encapsulation key through the already established encrypted channel, derive new secrets, and re-key both directions without tearing the connection down. Taken together, these mechanisms give DKTP a materially stronger lifecycle model than conventional tunnel profiles that only negotiate once and then run until expiry.
From a system perspective, this dual-entropy lifecycle establishes continuous forward evolution of both session and persistent key material, eliminating the concept of a static trust baseline. Each interaction incrementally reshapes the cryptographic state, reducing the value of any previously captured material and constraining the utility of delayed compromise. This property is particularly relevant in long-lived infrastructure tunnels, where DKTP maintains cryptographic freshness and state progression without introducing additional coordination overhead or renegotiation complexity.
Fixed 21-byte packet headers and directionally isolated key material constrain replay, ordering, and tunnel ambiguity
The specification gives DKTP one packet envelope for both handshake and transport. The same serialized header becomes part of the authenticated context for message signing, transcript formation, and encrypted traffic validation.
Directional derivation semantics
(tckl, nl) ← cSHAKE512(key = secl, custom = "DKTP:TXKEY:V1", data = pssr)
pssl ← cSHAKE512(pssl, ⊥, tckl[0:32])
(tckr, nr) ← cSHAKE512(key = secr, custom = "DKTP:RXKEY:V1", data = pssl)
pssr ← cSHAKE512(pssr, ⊥, tckr[0:32])
Packet envelope
| Field | Size | Function |
|---|---|---|
| Flag | 1 byte | Handshake stage, encrypted message, ratchet request, or error signaling |
| Sequence | 8 bytes | Strict ordering and replay rejection |
| Length | 4 bytes | Authenticated payload sizing and input validation |
| UTC time | 8 bytes | Freshness window and anti-replay control |
| Payload | Variable | Signed handshake material or RCS-protected transport data |
Formal treatment covers authentication, confidentiality, replay resistance, forward secrecy, and ratchet security
The formal analysis models an active adversary that can inject, replay, reorder, and manipulate traffic, reveal selected ephemeral or long-term values, and query the protocol through standard secure-channel games. Security claims are reduced explicitly to the underlying primitives and implementation assumptions.
Security properties proved or reduced in the formal model
- Authentication reduces to EUF-CMA security of the selected post-quantum signature scheme and correct peer-key validation.
- Handshake confidentiality and key indistinguishability reduce to IND-CCA security of the KEM together with pseudo-randomness of the domain-separated Keccak-based KDF.
- Tunnel confidentiality and integrity are modeled under the confidentiality and authentication assumptions of the RCS AEAD construction.
- Replay resistance and ordering are enforced by authenticated sequence numbers, timestamp checks, and strict exchange-flag progression.
- Forward secrecy, post-compromise recovery, and ratchet security depend on fresh KEM inputs, erasure of ephemeral state, and continued PSK advancement across sessions.
Compromise and lifecycle analysis
The formal paper explicitly treats compromise of long-term signing keys, directional PSKs, ephemeral KEM material, and established tunnel keys through oracle-based freshness conditions. The key result is that no single compromise category reconstructs the full directional channel state unless the adversary also defeats the remaining cryptographic dependencies.
The implementation-conformance section reinforces this by requiring secure erasure of ephemeral decapsulation keys, derived shared secrets, tunnel keys, nonces, and provisional buffers after use. DKTP is therefore analyzed not only as an abstract protocol, but as a state machine whose security depends on correct state destruction as well as cryptographic hardness.
Long-lived tunnels with deterministic behavior and bounded cryptographic ambiguity
DKTP is designed for deployments in which the tunnel itself is part of the security boundary rather than a generic transport convenience. Peering keys are provisioned out of band, the protocol configuration is fixed in advance, and each side maintains explicit local knowledge of the remote host it is permitted to communicate with. This sharply reduces negotiation ambiguity and makes the runtime behavior easier to reason about than large general-purpose secure-channel frameworks. Tunnel activation is delayed until both peers have not only completed the exchange but also successfully transported and compared the rolling transcript hash under the new channel state, which prevents the connection from entering service under partially matched or tampered handshake history.
Once established, the tunnel enforces strict sequencing and freshness rules through authenticated packet headers, with immediate teardown on error. The mandatory PSK update path means that repeated sessions between the same peers do not behave like repeated independent negotiations over static provisioning material; the tunnel relationship evolves. Where operational doctrine demands additional entropy injection without reconnecting, the asymmetric ratchet can re-key the channel in place. This makes DKTP particularly well aligned with infrastructure that values deterministic control, auditable behavior, and long-horizon confidentiality more than broad negotiation flexibility.
Deployment fit
DKTP is particularly well aligned with secure networking vendors, sovereign infrastructure operators, defense and intelligence systems, financial backbones, and protected industrial or field-deployed equipment where long-term confidentiality and controlled trust relationships matter more than interoperability with commodity public PKI ecosystems.
| Role in stack | Foundational high-assurance tunneling and transport primitive |
|---|---|
| Primary buyers | Secure networking, defense contractors, sovereign infrastructure, high-assurance system developers |
| Replacement case | Classical VPN, TLS tunnel, and SSH-adjacent secure-channel architectures |