diff --git a/docs/en/specification.md b/docs/en/specification.md new file mode 100644 index 0000000..4915309 --- /dev/null +++ b/docs/en/specification.md @@ -0,0 +1,122 @@ +# 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). diff --git a/docs/ru/specification.md b/docs/ru/specification.md new file mode 100644 index 0000000..1f8a32e --- /dev/null +++ b/docs/ru/specification.md @@ -0,0 +1,122 @@ +# Спецификация Ospab Stealth Transport Protocol (OSTP) + +**Версия:** 1.0 (Май 2026) +**Авторы:** Георгий С., Ospab Foundation +**Статус:** Стабильный, Информационный + +--- + +## 1. Введение + +**Ospab Stealth Transport Protocol (OSTP)** — это высокоэнтропийный мультиплексируемый транспортный протокол 4-го уровня, разработанный для безопасной и отказоустойчивой передачи данных между распределенными узлами в сетях с сильными помехами и агрессивным глубоким анализом трафика (DPI). + +Стандартные туннельные протоколы (такие как OpenVPN, WireGuard) генерируют паттерны трафика, которые легко распознаются системами DPI по статичным «магическим байтам», фиксированным размерам рукопожатий или предсказуемым последовательностям. OSTP решает эту проблему, применяя математическое маскирование состояния и рандомизированное выравнивание границ пакетов перед отправкой в сеть. Главная цель архитектуры — достижение **максимальной равномерной энтропии**, при которой UDP-датаграммы статистически неотличимы от чистого белого шума. + +--- + +## 2. Криптографические примитивы + +OSTP построен исключительно на базе стандартизированных современных криптографических алгоритмов: + +| Компонент | Примитив / Стандарт | Назначение | +|---|---|---| +| **Рукопожатие (Handshake)** | Noise Protocol Framework (`Noise_NNpsk0`) | Взаимная аутентификация и обмен ключами с прямой секретностью (Forward Secrecy). | +| **Обмен ключами** | X25519 (RFC 7748) | Эфемерный протокол Диффи-Хеллмана на эллиптических кривых. | +| **Симметричное шифрование** | ChaCha20-Poly1305 (RFC 8439) | Аутентифицированное шифрование (AEAD) для всех полезных данных. | +| **Хеширование** | BLAKE2s (RFC 7693) | Внутреннее хеширование состояний в рамках фреймворка Noise. | +| **Маскирование заголовков** | HMAC-SHA-256 (RFC 2104) | Динамическое искажение заголовков каждого пакета для устранения статических сигнатур. | + +--- + +## 3. Архитектура протокола + +OSTP работает в парадигме клиент-сервер поверх одного двунаправленного UDP-сокета: +* **Relay Bridge (Клиент / Инициатор):** Устанавливает соединения, генерирует идентификаторы сессий (Session ID) и инициирует криптографическое рукопожатие. +* **Collector Node (Сервер / Отвечающий):** Принимает соединения, проверяет ключи доступа и ретранслирует трафик прикладного уровня. + +OSTP поддерживает **внутреннее криптографическое мультиплексирование**, позволяя передавать несколько логических потоков данных через единый сокет без эффекта блокировки начала очереди (Head-of-Line blocking). + +--- + +## 4. Формат кадра (Спецификация заголовков) + +Сериализованный пакет OSTP соответствует физическим ограничениям MTU. Кадр состоит из предварительно замаскированного заголовка и зашифрованной полезной нагрузки с выравнивающим отступом (padding). Все многобайтовые поля используют сетевой порядок байт (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 ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| Замаскированный Session ID (32 бита) | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | ++ Открытый Nonce (64 бита) + +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| | +~ AEAD-шифротекст (Переменная длина) ~ +| | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +| 16-байтный тег Poly1305 | ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +``` + +### 4.1 Описание полей + +* **Замаскированный Session ID (32 бита):** Идентификатор сессии, замаскированный операцией XOR с использованием псевдослучайного потока, сгенерированного через HMAC-SHA-256. +* **Открытый Nonce (64 бита):** Монотонно возрастающий счетчик, используемый для отслеживания пакетов в ARQ и в качестве вектора инициализации (IV) для шифра AEAD. Передается в открытом виде, но полностью защищен от подмены (аутентифицирован как AAD в AEAD). +* **AEAD-шифротекст:** Внутренняя полезная нагрузка, зашифрованная ChaCha20-Poly1305. +* **Тег аутентификации (MAC):** 16-байтный код, гарантирующий целостность шифротекста и заголовков. + +--- + +## 5. Обфускация трафика (IPMS) + +Чтобы гарантировать статистическую независимость поля Session ID в последовательных пакетах, OSTP использует метод **In-Place Matrix Scrambling (IPMS)** на базе HMAC-SHA-256. + +1. **Генерация ключа обфускации:** + Оба узла независимо генерируют 8-байтный ключ обфускации (`K_obf`) из общего ключа доступа перед началом рукопожатия: + `K_obf = SHA-256(access_key || "obfusca")[0..7]` + +2. **Попакетное маскирование:** + Session ID маскируется уникальным псевдослучайным значением для каждого пакета: + `mask[0..3] = HMAC-SHA-256(K_obf, Nonce)[0..3]` + `Masked_SID = SID_raw XOR mask` + +Так как `Nonce` уникален для каждого пакета, маска криптографически независима для каждой датаграммы. Пассивный анализатор (DPI) не может связать пакеты в единую сессию без знания `K_obf`. + +--- + +## 6. Рукопожатие и криптографическая синхронизация + +OSTP использует Noise Protocol Framework с паттерном `Noise_NNpsk0_25519_ChaChaPoly_BLAKE2s`. + +1. Регистрационный ключ доступа (`access_key`) преобразуется в 32-байтный строгий предварительно распределенный ключ (PSK) через SHA-256. +2. PSK применяется на нулевой позиции паттерна, обеспечивая авторизацию и шифрование самой первой датаграммы рукопожатия (Zero-RTT авторизация). +3. Выполняется эфемерный обмен ключами Curve25519 для создания симметричных ключей передачи данных. + +Первичная полезная нагрузка рукопожатия содержит Unix-отметку времени для защиты от атак повторного воспроизведения (Replay Attacks). Сервер строго контролирует окно синхронизации (±30 секунд). + +--- + +## 7. Надежность и канал передачи данных + +### 7.1 Selective-Repeat ARQ +OSTP обеспечивает надежную доставку поверх UDP с помощью механизма **Selective-Repeat ARQ**: +* Приемник поддерживает буфер переупорядочивания (по умолчанию: 8192 пакета). +* Неподтвержденные пакеты отправляются повторно после адаптивного тайм-аута (RTO). +* Подтверждения (ACK) встраиваются в исходящие кадры данных (piggybacking) для минимизации накладных расходов. +* Протокол динамически применяет "обратное давление" (backpressure), ограничивая чтение новых данных, если число неподтвержденных кадров в полете слишком велико. + +### 7.2 Адаптивный Padding +Для защиты от анализа длин пакетов (Packet Length Analysis, PLA), OSTP добавляет выравнивающий отступ к открытому тексту перед AEAD-шифрованием. Байты отступа берутся из криптографически стойкого генератора псевдослучайных чисел ОС. Протокол поддерживает динамическое выравнивание вплоть до полного размера MTU (например, 1400 байт), сглаживая узнаваемые всплески трафика приложений и превращая их в подобие CBR (Constant Bit Rate) потока. + +### 7.3 IP-роуминг (IP Roaming) +Сервер поддерживает бесшовную смену сетей (например, переключение со смартфона с Wi-Fi на LTE). Если сервер получает пакет с новым IP-адресом отправителя, но пакет успешно проходит AEAD-аутентификацию с использованием текущих ключей, сервер автоматически привязывает эту сессию к новому IP-адресу без обрыва соединения. + +--- + +## 8. Безопасность (Security Considerations) + +* **Исчерпание Nonce:** Поле Nonce имеет размер 64 бита. Реализации ОБЯЗАНЫ разрывать сессию до переполнения Nonce, чтобы предотвратить катастрофическое повторное использование гаммы AEAD-шифра. +* **DDoS и исчерпание ресурсов:** Серверы ДОЛЖНЫ применять жесткий лимит на количество одновременных сессий (например, 1024) и молча отбрасывать запросы на рукопожатие при превышении лимита, предотвращая атаки на исчерпание памяти. +* **Целостность заголовка:** Механизм маскирования обеспечивает только скрытность, а не целостность. Целостность заголовков математически гарантируется 16-байтным тегом аутентификации Poly1305, который покрывает 12-байтный заголовок как присоединенные данные (AAD).