ostp/docs/en/specification.md

123 lines
7.2 KiB
Markdown

# Ospab Stealth Transport Protocol (OSTP) Specification
**Version:** 1.0 (May 2026)
**Authors:** Georgiy S., Ospab Foundation
**Status:** Stable, Informational
---
## 1. Introduction
The **Ospab Stealth Transport Protocol (OSTP)** is a high-entropy, multiplexed Layer 4 transport pipeline developed to achieve secure, resilient data replication between distributed nodes across networks characterized by severe stochastic disturbance and hostile packet-level telemetry inspections (Deep Packet Inspection / DPI).
Standard tunneling protocols (e.g., OpenVPN, WireGuard) produce traffic patterns that are reliably identified by stateful DPI systems through static magic bytes, fixed handshake sizes, or predictable sequence patterns. OSTP addresses this threat model by employing mathematical state scrambling and randomized frame-boundary injection prior to final serialization. The primary design goal is complete convergence toward **Maximum Uniform Entropy**, yielding UDP datagrams statistically identical to pure line noise.
---
## 2. Cryptographic Primitives
OSTP is built strictly upon standardized, modern cryptographic primitives:
| Component | Primitive / Standard | Purpose |
|---|---|---|
| **Handshake** | Noise Protocol Framework (`Noise_NNpsk0`) | Mutual authentication and forward-secret key exchange. |
| **Key Agreement** | X25519 (RFC 7748) | Ephemeral Elliptic Curve Diffie-Hellman. |
| **Symmetric Encryption** | ChaCha20-Poly1305 (RFC 8439) | Authenticated Encryption with Associated Data (AEAD) for all payload data. |
| **Hashing** | BLAKE2s (RFC 7693) | Noise internal state hashing and mixing. |
| **Obfuscation Masking** | HMAC-SHA-256 (RFC 2104) | Per-packet header scrambling to eliminate static byte signatures. |
---
## 3. Protocol Architecture
OSTP operates in a client-server paradigm over a singular bidirectional UDP socket:
* **Relay Bridge (Client / Initiator):** Establishes connections, generates Session IDs, and drives handshake initiation.
* **Collector Node (Server / Responder):** Accepts connections, validates credentials, and relays application-layer traffic.
OSTP supports **internal cryptographic multiplexing**, allowing multiple logical sub-streams to occupy the shared socket state without head-of-line blocking.
---
## 4. Frame Format (Wire Specification)
An OSTP packet serialized for transport conforms to physical MTU alignments. Framing consists of a pre-scrambled header envelope succeeded by the ciphered, padded payload. All multi-byte fields use network byte order (big-endian).
```text
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Masked Session Identifier (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Plaintext Nonce (64 bits) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ AEAD Ciphertext (Variable Length) ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-Octet Poly1305 Authentication Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```
### 4.1 Field Descriptions
* **Masked Session Identifier (32 bits):** The Session ID XOR-masked with a pseudorandom stream generated by HMAC-SHA-256.
* **Plaintext Nonce (64 bits):** A monotonically increasing counter used for ARQ sequence tracking and as the AEAD cipher IV. Transmitted in plaintext, but fully authenticated via AEAD AAD.
* **AEAD Ciphertext:** The inner payload encrypted with ChaCha20-Poly1305.
* **Authentication Tag:** The 16-byte MAC ensuring ciphertext and header integrity.
---
## 5. Traffic Obfuscation (IPMS)
To ensure that the Session ID field is statistically independent across consecutive packets, OSTP employs **In-Place Matrix Scrambling (IPMS)** using HMAC-SHA-256.
1. **Obfuscation Key Derivation:**
Both nodes independently derive an 8-byte obfuscation key (`K_obf`) from the shared access key prior to the handshake:
`K_obf = SHA-256(access_key || "obfusca")[0..7]`
2. **Per-Packet Masking:**
The Session ID is masked using a per-packet pseudorandom value:
`mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]`
`Masked_SID = SID_raw XOR mask`
Because the `Nonce` is unique per packet, the mask is cryptographically independent for every datagram. A passive observer cannot correlate packets to a single session without knowledge of `K_obf`.
---
## 6. Handshake and Cryptographic Synchronization
OSTP executes a Noise Protocol Framework exchange utilizing the `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s` pattern.
1. The Registration Key (`access_key`) is converted to a 32-octet strong pre-shared key (PSK) via SHA-256.
2. The PSK is integrated into the state at pattern position zero, authorizing and encrypting the very first handshaking datagram.
3. Ephemeral Curve25519 key exchange is evaluated to synthesize autonomous symmetric keys for subsequent read/write channels.
The initial handshake payload includes a Unix timestamp to mitigate replay attacks. The server enforces a strict ±30-second synchronization window.
---
## 7. Reliability and Data Channel
### 7.1 Selective-Repeat ARQ
OSTP provides reliability over UDP using a **Selective-Repeat ARQ** mechanism:
* The receiver maintains a reorder buffer (default: 8192 packets).
* Unacknowledged packets are retransmitted after an adaptive Retransmission Time Out (RTO).
* Acknowledgments (ACKs) are piggybacked onto outbound data frames to minimize overhead.
* Backpressure is applied dynamically based on the number of in-flight unacknowledged frames.
### 7.2 Adaptive Padding
To resist traffic analysis via Packet Length Analysis (PLA), OSTP pads plaintext payloads before AEAD encryption. Padding bytes are drawn from a cryptographically secure random source. The protocol supports dynamic padding boundaries up to the maximum MTU (e.g., 1400 bytes), smoothing out recognizable application traffic bursts into constant-bitrate-like streams.
### 7.3 IP Roaming
The server supports seamless network handoffs (e.g., transitioning from Wi-Fi to cellular networks). If a packet successfully passes AEAD authentication, the server automatically binds the Session ID to the new source IP address without requiring a session restart.
---
## 8. Security Considerations
* **Nonce Exhaustion:** The Nonce field is 64 bits. Implementations MUST terminate and re-key a session before the Nonce overflows to prevent AEAD keystream reuse.
* **Session Exhaustion (DoS):** Servers MUST enforce a strict cap on concurrent sessions (e.g., 1024) and silently drop handshake attempts exceeding this limit to prevent memory exhaustion attacks.
* **Header Authentication:** The header obfuscation mechanism provides privacy, not integrity. Header integrity is mathematically guaranteed by the Poly1305 Authentication Tag, which covers the entire 12-byte header as Additional Authenticated Data (AAD).