OMasX — Omni Masked eXchange

The next-generation transport protocol for privacy, adaptability, and speed

Overview

OMasX is a universal, masked, and secure data transport protocol designed to protect user privacy and conceal VPN usage by avoiding standard traffic signatures. As a natural consequence, it effectively resists censorship, blocking, and Deep Packet Inspection (DPI) techniques based on signature analysis.

Design Principles

• Omni: a unified stack for both mobile and desktop networks.
• Masked: mimics legitimate traffic patterns (TLS/HTTPS-like behavior).
• eXchange: adaptive data exchange optimized for dynamic environments (Wi-Fi, Cellular, Proxy).

Key Features

How It Works

1. The client and server exchange a masked handshake.
2. An encrypted channel is established; keys are refreshed periodically or by traffic volume.
3. Data is encapsulated and sent via UDP/TCP with adaptive header compression.

Security (Triple Encryption)

The architecture implements a three-layer security model (defense-in-depth): each layer protects a different exposure surface and compensates for the residual weaknesses of the previous layer.

1. Layer 1 — Application TLS (HTTPS)
   TLS (typically HTTPS/TLS 1.3) protects application payloads and ensures content confidentiality and integrity between the client application (e.g., browser) and the destination service. What remains exposed: network- and transport-level metadata such as IP addresses, packet timing/volume, DNS requests, and some TLS handshake metadata. These observables can still be analyzed by ISPs or DPI systems to infer user activity.


2. Layer 2 — IPsec / IKEv2 wrapper
   Wrapping traffic in IPsec (IKEv2) encrypts both application data and network headers, ensuring strong confidentiality and integrity across the transport channel. Residual exposure and fingerprinting risk: despite encrypting headers and payloads, IPsec/IKEv2 still leaves detectable protocol-level signatures — such as fixed packet sizes, packet counters, timing patterns, and handshake identifiers — which can allow DPI systems to classify the flow as VPN traffic.
   AEAD ciphersuites:
   • ChaCha20-Poly1305 — default for mobile and high-latency networks.
   • AES-256-GCM — hardware-accelerated where supported.
   • AES-128-GCM — for lightweight or embedded environments.
   These suites ensure authenticated encryption and integrity protection at the IPsec layer while maintaining high performance across a wide range of devices and platforms.


3. Layer 3 — OMasX masking transport
   OMasX acts as the outermost adaptive layer that encapsulates and masks all previous layers. Its design eliminates recognizable protocol structures and metadata by:
   • avoiding static protocol headers and fixed-length framing;
   • using cover traffic that imitates common Internet protocols (TLS, QUIC, HTTP/2, etc.), rotated per-profile;
   • applying dynamic padding and probabilistic packet length shaping;
   • implements proprietary per-packet cryptographic transformations designed to conceal protocol signatures while remaining computationally lightweight for real-time masking and unmasking.
   This layer introduces no persistent metadata of its own and renders the overall traffic statistically and cryptographically indistinguishable from ordinary Internet communication, effectively concealing the fact that a VPN tunnel is in use.

┌────────────────────────────────────────────────────────────┐
│                Layer 3 — OMasX Masking Transport           │
│  • Traffic masking and protocol camouflage                 │
│  • Dynamic padding, fake headers, key rotation             │
│  • No exposed metadata / protocol signatures               │
│                                                            │
│   ┌────────────────────────────────────────────────────┐   │
│   │           Layer 2 — IPsec / IKEv2 Wrapper          │   │
│   │  • AEAD encryption (ChaCha20-Poly1305, AES-GCM)    │   │
│   │  • Encrypts data + transport headers               │   │
│   │  • Residual VPN fingerprints (packet counters, SNi)│   │
│   │                                                    │   │
│   │   ┌────────────────────────────────────────────┐   │   │
│   │   │    Layer 1 — Application TLS (HTTPS)       │   │   │
│   │   │  • Protects user payloads with TLS 1.3     │   │   │
│   │   │  • Exposes IP addresses, DNS, metadata     │   │   │
│   │   └────────────────────────────────────────────┘   │   │
│   └────────────────────────────────────────────────────┘   │
└────────────────────────────────────────────────────────────┘

Triple-layer model:
(1) HTTPS → (2) IPsec → (3) OMasX

Summary: the stack operates hierarchically — HTTPS/TLS protects application payloads, IPsec/IKEv2 secures both data and headers but remains fingerprintable, and OMasX provides an additional masking layer that removes protocol signatures and metadata exposure, ensuring complete traffic deniability.

Transport

Although OMasX encapsulates IPsec/IKEv2 in its base implementation, it does not require separate ports for the handshake and data channels. All control and data exchange can operate through a single UDP port within the range 1–65535, chosen dynamically or configured manually. This unified transport design simplifies traversal through firewalls and NAT devices and minimizes the protocol’s observable footprint.

At the same time, OMasX supports simultaneous multi-port operation. It can maintain parallel connections over multiple UDP or TCP ports — or dynamically switch between them — without interrupting the active session.

Performance

Recommended MTU/MSS, socket buffers, and timing parameters (to be filled). Typical latency and throughput benchmarks across network types.

Compatibility

Clients: iOS and macOS (production); Android (in development).
Servers: Linux, FreeBSD (production).

Specification

Example of serialized OMasX packet (hexadecimal):

+-----------------------------+------------------------------+
| Fake Header (opt. 0-256)    | Mask Key (>=4 bytes)         | 
+-----------------------------+------------------------------+
+-----------------------------+------------------------------+
| Masked Payload (variable)                                  | 
+------------------------------------------------------------+
+-----------------------------+------------------------------+
| Dynamic Padding (0-256)     | Masked Footer (few bytes)    |
+-----------------------------+------------------------------+

Field details
-------------
Fake Header (0..256 bytes)  — optional, cleartext. Purpose: emulate common protocol headers to blend in.
  - May contain arbitrary bytes that mimic QUIC/TLS/HTTP/etc.
  - Example (TLS-like prefix): 16 03 01 ... (appears like TLS record header)
  - If present, treated purely as cover data and not used for cryptographic state.

Mask Key (L >= 4 bytes)  — encrypted/obfuscated keying blob for masking layer
  - Length encoded implicitly or fixed by profile.
  - Carries session-specific mask/enc keys.
  - Minimum 4 bytes; typical length 16..64 depending on key-wrapping scheme.

Masked Payload (variable)  — AEAD-encrypted application payload
  - Content encrypted with negotiated AEAD (e.g., ChaCha20-Poly1305 / AES-GCM).
  - Associated Data (AAD) may include portions of FakeHeader or header metadata (profile-dependent).
  - Length determined by payload length field in the masked footer or by separate framing.

Dynamic Padding (0..256 bytes)  — random or deterministic padding to obscure length
  - Can be zero-length.
  - Size distribution controlled by masking profile (to avoid consistent lengths).

Footer (few bytes)  — compact masked footer containing minimal service info
  - Small fixed-length block (profile-dependent) — contains framing / routing / nonce index / truncated auth info.
  - Structure intentionally obfuscated; exact field layout not published here.
  - Footer must be sufficient to allow receiver to validate & demask packet (but size kept minimal).
    

FAQ

Is this a VPN or a standalone transport?
OMasX can serve as a standalone transport layer or as part of a VPN solution.

Can OMasX be broken or demasked?
An analyst could spend a huge amount of time and effort and eventually obtain nothing more than a packet counter number — and would have to start over for the next packet. User data, IP addresses, and DNS queries remain reliably and cryptographically protected by the inner layers (IPsec and TLS).

Implementations

• Astra VPN (macOS)
• Astra VPN (iOS)

Credits

Developed independently with analytical, creative, and linguistic support from OpenAI GPT.

Legal Notice

The OMasX protocol is designed as a privacy-enhancing technology intended to protect the confidentiality and anonymity of user communications. Its primary purpose is to improve the security, resilience, and integrity of network transport against unauthorized interception and traffic analysis.

OMasX must not be used for any activity that violates applicable local, national, or international laws. This includes, but is not limited to: unauthorized access to computer systems or data, distribution of malicious content, fraud, circumvention of lawful content restrictions, or any other form of illegal network activity.

While OMasX provides mechanisms for encryption, masking, and metadata protection, the responsibility for lawful and ethical use lies solely with the end user, operator, or organization deploying the technology. Developers and maintainers of the OMasX specification disclaim all liability for misuse of the protocol in violation of applicable regulations or third-party rights.

In summary, OMasX is a tool for privacy protection — not for evading legitimate security controls or regulatory frameworks. Users are encouraged to comply with the laws and policies of their respective jurisdictions when deploying or operating OMasX-based systems.