What is HyperSox Protocol? A Technical Deep Dive

HyperSox is an application-layer encrypted proxy protocol built entirely in Rust by OneDotNet Ltd. It was designed from the ground up for environments where conventional VPN protocols — including WireGuard and OpenVPN — are routinely detected and blocked by deep packet inspection (DPI) systems.

Where WireGuard achieves exceptional speed through a minimal kernel-resident implementation, HyperSox goes further: it makes your encrypted traffic look indistinguishable from ordinary HTTPS browsing to any network observer. This document is the authoritative technical reference for the HyperSox protocol.

Why a New Protocol?

Existing protocols face a fundamental problem in DPI-heavy environments:

WireGuard: UDP-only with a recognizable packet signature. Trivially blocked.
OpenVPN: TCP/UDP but has a well-known TLS fingerprint. Blocked by most national-level DPI.
VLESS/VMess: Widely deployed but now part of DPI signature databases.
sing-box: Excellent multi-protocol support but 42.59 MB binary and 33.81 MB idle memory — too heavy for mobile.

HyperSox's answer: build a new protocol that is simultaneously smaller, faster, and completely invisible to DPI.

Encryption Foundation

ChaCha20-Poly1305 AEAD

All HyperSox data channels use ChaCha20-Poly1305 authenticated encryption, the same AEAD construction used by WireGuard and TLS 1.3. Every frame is:

Encrypted with ChaCha20 (256-bit key, 96-bit nonce)
Authenticated with Poly1305 (128-bit MAC tag)

This means any in-transit modification is immediately detectable — bit-flipping, injection, and truncation attacks are cryptographically impossible.

Key Derivation

Static session keys are derived using BLAKE3-KDF:

key = BLAKE3-KDF("hypersox-v1-key", uuid_bytes || password_bytes)

This produces a 32-byte encryption key from the user's UUID and password. BLAKE3 was chosen over SHA-256 and BLAKE2 for its superior performance on modern CPUs (particularly ARM) while maintaining equivalent security properties.

Frame Structure Constraints

Key size: 32 bytes
Nonce size: 12 bytes
Auth tag size: 16 bytes (Poly1305)
Maximum frame size: 65,519 bytes (slightly under the 65,535 byte UDP limit to leave room for headers)

Forward Secrecy (Introduced in v2.1)

Static key derivation from UUID and password provides authentication, but not forward secrecy. If an attacker records encrypted traffic and later obtains the static key, they can decrypt all past sessions.

HyperSox v2.1 solved this with a full ephemeral key exchange layer.

X25519 Key Exchange

At the start of each session, both client and server generate fresh X25519 ephemeral key pairs. The X25519 Diffie-Hellman exchange produces a shared secret that is unique to this session and discarded after use — past sessions are irrecoverable even if static keys are compromised.

Ed25519 Handshake Authentication

The handshake is authenticated using Ed25519 signatures. Each peer signs their ephemeral public key along with the session timestamp. This prevents:

MITM attacks: A forged ephemeral key would fail signature verification
Replay attacks: The timestamp ensures old handshake messages can't be replayed

Session Key Derivation

Session keys are derived via HKDF-SHA256:

SessionKey = HKDF-SHA256(SharedSecret || StaticKey, Timestamp || Nonce)

This binds the ephemeral shared secret to the static key material, so both authentication factors must be correct for a valid session key to be derived.

Key Rotation Policy

Session keys are automatically rotated:

Every 1 hour of active use
After 1 million packets sent
After 1 GB of data transferred (whichever comes first)

This limits the exposure window of any individual session key.

Handshake Format

The HyperSox v2.1 handshake packet has the following binary structure:

+----------+--------+-------------+-------+---------+
| Version  | UUID   | Timestamp   | Nonce | Command |
| 1 byte   | 16 bytes| 4 bytes    | 12 bytes| 1 byte |
+----------+--------+-------------+-------+---------+
+-------------------+-----------------+
| Target Address    | Target Port     |
| variable          | 2 bytes         |
+-------------------+-----------------+
+----------------------+-------------------+
| ClientPubKey X25519  | Ed25519 Signature |
| 32 bytes             | 64 bytes          |
+----------------------+-------------------+

Field descriptions:

| Field | Size | Description | |-------|------|-------------| | Version | 1B | Protocol version (0x21 for v2.1) | | UUID | 16B | Client identity, used for key derivation | | Timestamp | 4B | Unix timestamp (seconds), replay protection | | Nonce | 12B | Random nonce for this session | | Command | 1B | 0x01=TCP Connect, 0x03=UDP Associate | | Target Address | Variable | ATYP (1B) + address | | Target Port | 2B | Big-endian destination port | | ClientPubKey | 32B | Ephemeral X25519 public key | | Ed25519 Sig | 64B | Signature over all preceding fields |

Traffic Obfuscation (v2.2)

This is what makes HyperSox fundamentally different from any protocol that came before it. Three independent obfuscation layers work in concert.

Layer 1: REALITY TLS Masquerading

REALITY is a technique for making proxy traffic appear as HTTPS connections to real, legitimate websites.

Here's how it works:

The HyperSox server is configured with a real "front domain" — for example, a major CDN or cloud provider endpoint.
When a client connects, the TLS handshake genuinely completes with the front domain's certificate (via an SNI routing trick). To any observer inspecting TLS metadata, the connection looks completely real.
Client authentication tokens are embedded steganographically in the TLS Session Ticket field — a legitimate TLS extension that carries an opaque blob from the server's perspective.
The server recognizes its own client by decoding the session ticket, then breaks out of the TLS front and routes to the actual HyperSox backend.

Result: your connection to the FastSox server is TLS-indistinguishable from a real HTTPS connection to a legitimate website. No special TLS fingerprint, no suspicious certificate, no unusual cipher suites.

Layer 2: uTLS Browser Fingerprint Spoofing

Standard TLS implementations produce unique fingerprints — a combination of supported cipher suites, TLS extensions, elliptic curves, and extension ordering that identifies the client library (e.g., "this is Go's crypto/tls", "this is OpenSSL 3.0").

uTLS solves this by mimicking the exact TLS ClientHello format of real browsers:

Chrome 117: Specific cipher suite ordering, GREASE values, extension set
Firefox 118: Different extension ordering, different supported groups
Safari 16: iOS/macOS-specific fingerprint

Additionally, GREASE (Generate Random Extensions and Sustain Extensibility) values — random, ignored extension values included by Chrome to prevent ossification — are randomized with each connection. This makes fingerprinting the uTLS implementation itself impossible.

Layer 3: WebSocket Encapsulation

As a final optional transport layer, HyperSox can encapsulate all traffic as WebSocket frames (RFC 6455). WebSocket connections:

Start with a standard HTTP Upgrade handshake (looks like legitimate web traffic)
Are indistinguishable from WebSocket-using web applications (Slack, Discord, etc.)
Allow HyperSox to traverse restrictive corporate proxies that pass WebSocket but block raw TCP

Multi-Transport Support

HyperSox supports three transport modes, selected based on network conditions:

| Transport | Port | RTT | Use Case | |-----------|------|-----|----------| | TCP | 8443 | Baseline | Default, maximum compatibility | | UDP Associate | Dynamic | Lower | Bidirectional UDP tunneling | | QUIC | 8443 | Lowest (0-RTT) | High-performance, loss-tolerant networks |

QUIC transport with 0-RTT session resumption is particularly valuable for mobile users with frequent network transitions — the session can be resumed without a full handshake when switching between Wi-Fi and cellular.

Performance: HyperSox vs sing-box

sing-box v1.12.17 is the most widely deployed multi-protocol proxy runtime. HyperSox's Rust implementation offers dramatic improvements in operational efficiency:

| Metric | HyperSox | sing-box v1.12.17 | Improvement | |--------|----------|-------------------|-------------| | Binary size | 6.41 MB | 42.59 MB | -85% | | Startup time | 2.47 ms | 11.19 ms | -78% | | Memory (idle) | 5.35 MB | 33.81 MB | -84% | | Throughput | ~950 Mbps | ~800 Mbps | +19% |

These gains come from Rust's zero-cost abstractions, absence of a garbage collector, and compile-time memory safety — no runtime overhead, no GC pauses, no memory allocator thrashing.

For mobile deployments, the memory and startup numbers matter most: HyperSox can initialize a full VPN tunnel before the user's finger lifts from the Connect button.

Protocol Version History

HyperSox has evolved rapidly since its initial release:

| Version | Key Features | |---------|-------------| | v1.0 | TCP transport only, static ChaCha20-Poly1305 keys, single-user | | v2.0 | UDP Associate support, QUIC transport, multi-user (UUID-based) | | v2.1 | X25519 ephemeral key exchange, Ed25519 signatures, full forward secrecy | | v2.2 | REALITY TLS masquerading, uTLS fingerprint spoofing, WebSocket encapsulation |

The current production release is v2.2, deployed across all FastSox gateways.

Security Properties Summary

| Property | HyperSox v2.2 | |----------|---------------| | Encryption | ChaCha20-Poly1305 AEAD | | Key exchange | X25519 ECDH | | Authentication | Ed25519 signatures | | Forward secrecy | Yes (ephemeral keys, 1-hour rotation) | | Replay protection | Timestamp + nonce | | Traffic obfuscation | REALITY + uTLS + WebSocket | | DPI resistance | High | | Side-channel resistance | High (constant-time operations) |

How HyperSox Relates to WireGuard

Both protocols share the same cryptographic DNA: ChaCha20-Poly1305 for AEAD, X25519 for key exchange, and HKDF for key derivation. HyperSox is best understood as a complement to WireGuard, not a replacement.

WireGuard is ideal when you need raw tunneling performance with no obfuscation requirements — corporate VPNs, home servers, trusted networks. HyperSox is the right choice when your network path includes DPI inspection that would block WireGuard's recognizable UDP signature.

FastSox runs both: WireGuard-based gateways for maximum throughput, HyperSox-based gateways for DPI-resistant access. The Smart Mode routing engine selects the appropriate gateway automatically.

For foundational VPN concepts, see What is a VPN?. For a deep dive into WireGuard's cryptography, see How WireGuard Works.

Ready to try HyperSox? Get started with FastSox — free plan available, no credit card required.