mirror of https://github.com/ospab/ostp.git
130 lines
8.6 KiB
Markdown
130 lines
8.6 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: 32768 packets) for out-of-order packet reassembly.
|
||
* Acknowledgments use a **Cumulative + SACK** scheme: the ACK payload contains a cumulative range `(0, expected_recv_nonce - 1)` confirming all contiguous packets received, plus up to 7 additional Selective ACK ranges for non-contiguous blocks in the reorder buffer.
|
||
* **Rate-limited NACK:** When a gap is detected, the receiver emits a NACK for the lowest missing nonce, but no more than once per 30ms. This prevents retransmission storms under normal UDP jitter.
|
||
* **Retransmission:** Unacknowledged data frames are retransmitted after an adaptive Retransmission Timeout (RTO, default: 100ms) with exponential backoff (up to 64× base RTO).
|
||
* **Zombie Frame Eviction:** Frames exceeding `max_retries + 4` attempts are automatically dropped from the send history, preventing unbounded memory consumption and stale retransmissions.
|
||
* **In-flight Counting:** Backpressure is based only on retransmittable (data) frames; control frames (ACK/NACK) are excluded from the in-flight count to prevent false backpressure under high load.
|
||
* **Graceful Close:** The `Closing` state processes all remaining in-flight packets before transitioning to `Closed`, preventing data loss during session teardown.
|
||
|
||
### 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. The server maintains a rate-limited roaming scanner (50 tokens/sec) to prevent CPU exhaustion from probing attacks.
|
||
|
||
### 7.4 Session Keepalive
|
||
* **Client-side:** Ping/Pong frames with RTT measurement are sent every 5 seconds. If no valid UDP packet is received for 60 seconds, the client initiates reconnection.
|
||
* **Server-side:** Sessions with no activity for 300 seconds are automatically evicted.
|
||
|
||
---
|
||
|
||
## 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).
|