QNyx 3.0.2 · Production · 100% Rust

The post-quantum tunnel that puts itself back together.

QNyx is a post-quantum native transport protocol from Xaoc Industries in Canada. It detects a dead link and re-establishes the tunnel in under 60 seconds, assigns its own addressing from ML-DSA-65 identity, and ships as a single 1 MB Rust binary that saturates gigabit Ethernet on a Raspberry Pi 5.

See the Numbers Operator's Manual (PDF) Request a Pilot
qnyx 3.0.2 / status
$ qnyx --version
QNyx 3.0.2 · 100% Rust · 1 MB

+ transport
throughput: 1 Gbps line rate
overhead: < 1 ms

+ autonomy
link loss: detected in 15 s
recovery: < 60 s
addressing: automatic

+ post-quantum
KEM: ML-KEM-1024
identity: ML-DSA-65
payload: HF8 + AES-GCM
rekey: 900 s

+ platform: Linux ARM64 / x64 · Android
✓ tunnel operational
<60 s Self-healing link recovery
1 Gbps Line rate on a Raspberry Pi 5
<1 ms Added latency overhead
1 MB Standalone Rust binary

QNyx 3.0.2 · Post-Quantum Transport

A post-quantum VPN designed around the network you actually have.

Networks are not clean laboratory environments. Links disappear. Packets arrive late. Routes change. Satellite connections move. Wireless links degrade. Battery-powered nodes drop off and come back.

QNyx is built around a simple premise: the network underneath the tunnel is allowed to be imperfect, and the tunnel is expected to deal with it on its own.

It is post-quantum native — ML-KEM-1024 key encapsulation and ML-DSA-65 identity are the protocol, not an optional cipher suite bolted onto a classical handshake. There is no legacy mode to fall back to and nothing to negotiate down.

Deployment, command syntax, firewall requirements, and log-based troubleshooting are documented in the QNyx 3.0.2 Operator's Manual .

  • Self-healing
    A dead link is detected and the tunnel is re-established in under 60 seconds.
  • Self-configuring
    Tunnel addressing is assigned automatically and bound to ML-DSA identity.
  • Post-quantum native
    ML-KEM-1024 and ML-DSA-65 with no classical fallback path.
  • 1 Gbps line rate on a Pi 5
    Gigabit Ethernet saturated by a single-board computer.
  • Under 1 ms added latency
    Encryption that does not become the bottleneck in the path.
  • 1 MB standalone binary, 100% Rust
    One file. No runtime, no dependencies, no kernel module.

Self-Healing & Self-Configuring

Nobody has to notice the link went down.

Most tunnels treat recovery as somebody else's job — a watchdog script, a monitoring alert, an operator with a laptop. QNyx treats it as part of the protocol. Loss of a peer is a normal event with a defined response, and that response completes in under a minute without a human, a controller, or a configuration change.

QNyx self-healing link recovery timeline When a link dies, QNyx detects the missed heartbeat at 15 seconds, re-runs the ML-KEM-1024 key exchange, and restores the tunnel on the same addresses in under 60 seconds with no operator action. LINK LOSS RECOVERY · NO OPERATOR IN THE LOOP TUNNEL UP · KEY K₁ CARRIER GONE · SESSION STATE HELD UP · K₂ RECOVERY RE-KEX · ML-KEM-1024 t = 0 HEALTHY LINK DIES PACKETS STOP +45 s HEARTBEAT TIMEOUT < 60 s TUNNEL RESTORED SAME TUNNEL IP THROUGHOUT · ADDRESS IS BOUND TO ML-DSA-65 IDENTITY, NOT TO THE LINK
Recovery is a protocol behaviour, not a runbook. A missed heartbeat marks the peer dead at 15 seconds; the node immediately re-runs the post-quantum key exchange and brings the tunnel back on the same addresses — well inside a minute, with nothing for an operator to restart.
Self-Healing

Under 60 seconds, end to end

QNyx nodes heartbeat continuously. When the far end stops answering, the session is declared dead at 45 seconds and recovery starts on its own: reconnect, re-run the ML-KEM-1024 handshake, re-verify the ML-DSA-65 identity, resume.

Retries back off progressively rather than hammering a network that is already in trouble, so a node on a flapping satellite or LTE link keeps trying without becoming part of the problem.

Self-Configuring

Addressing you never assign

There is no IP plan to maintain. QNyx allocates tunnel addressing automatically and ties each address to the peer's ML-DSA-65 public key, so a node keeps the same tunnel IP across reconnects, reboots, and changes of underlying network.

Enrolment is a file operation: drop a public key into the server's approved directory to admit a node, delete it to revoke one. The directory is re-read on every handshake — no restart, no config reload, no accounts, no passwords.

Post-Quantum Cryptography

ML-KEM and ML-DSA at the transport layer, not bolted on top.

Harvest-now-decrypt-later is not a future problem for traffic that has to stay confidential for a decade. QNyx 3.0.2 pairs the standardized post-quantum primitives — ML-KEM-1024 and ML-DSA-65 — with Xaoc's HF8 construction and authenticated encryption, and refreshes session material four times an hour whether or not anything looks wrong.

Key Encapsulation · FIPS 203

ML-KEM-1024

Post-quantum key encapsulation establishes every session, including each scheduled rekey and every recovery after a link loss.

Identity & Signatures · FIPS 204

ML-DSA-65

A node's ML-DSA-65 keypair is its identity. It authenticates the peer and determines the tunnel address that peer receives.

Payload Protection

HF8 + AES-GCM

Tunnel traffic is protected with HF8 alongside AES-GCM authenticated encryption, with 57 bytes of fixed overhead per packet.

QNyx 3.0.2 post-quantum packet structure A 11-byte QNyx header and payload are encrypted together, leaving only a 32-byte envelope, ciphertext and 16-byte tag on the wire, with no plaintext protocol headers. WHAT YOU HAND TO THE TUNNEL 11 B HEADER IP PAYLOAD UP TO 1410 B · NEGOTIATED MTU HF8 + AES-GCM · AUTHENTICATED WHAT AN OBSERVER SEES 32 B ENVELOPE CIPHERTEXT 16 B TAG 57 B FIXED OVERHEAD 1469 B MAX ON WIRE 0 PLAINTEXT PROTOCOL HEADERS
The QNyx header is encrypted with the payload, not alongside it. On the wire, a QNyx packet is a UDP datagram carrying a uniformly distributed blob — nothing to parse, nothing to fingerprint.

Performance / Proof

The numbers are the point.

Post-quantum cryptography has a reputation for being expensive. QNyx 3.0.2 saturates gigabit Ethernet from a $80 single-board computer and stays under a millisecond of added latency doing it.

1 Gbps

Line rate on a Raspberry Pi 5

QNyx saturates the Pi 5's gigabit Ethernet interface in-tunnel, with full post-quantum key exchange and authenticated payload encryption active. On 2.5 GbE hardware, measured in-tunnel throughput reaches 1100 Mbps.

<1 ms

Added latency

Sub-millisecond tunnel overhead, so QNyx is not the hop anyone blames.

<60 s

Link recovery

Dead link detected and tunnel re-established, unattended.

1 MB

Binary footprint

One standalone Rust binary, identical on every supported platform.

900 s

Rekey interval

Automatic post-quantum rekeying every fifteen minutes.

QNyx measured post-quantum throughput by platform Bar chart of in-tunnel throughput: 1100 megabits per second on a 2.5 gigabit router, 940 megabits per second at gigabit line rate on a Raspberry Pi 5, and 85 on a battery-powered Pi Zero 2 W over Wi-Fi. MEASURED IN-TUNNEL THROUGHPUT · Mbps 250 500 750 1000 1250 QNyx Router 2.5 GbE · PASSIVE 1100 Raspberry Pi 5 1 GbE · LINE RATE 940 Pi Zero 2 W 2.4 GHz Wi-Fi · BATTERY 85 SAME 1 MB RUST BINARY ON EVERY PLATFORM · NO REDUCED FEATURE SET
One binary, three classes of hardware. On the Raspberry Pi 5 the constraint is the network interface, not QNyx: the tunnel fills gigabit Ethernet. The same 1 MB executable also runs on a passively cooled 2.5 GbE router and a battery-powered Pi Zero — no separate builds, no cut-down mode.
Leamington Ontario to Sydney Australia QNyx tunnel A wireframe globe with an encrypted post-quantum tunnel arcing 15,500 kilometres from a battery-powered Raspberry Pi Zero 2 W in Leamington, Ontario, Canada to a Sydney, Australia endpoint. LEAMINGTON, ON CANADA · QNYX ENDPOINT RASPBERRY PI ZERO 2 W 3 × AAA BATTERIES SYDNEY AUSTRALIA · QNYX ENDPOINT POST-QUANTUM TUNNEL 15,500 km · 3.75 h · 3 AAA TUNNEL DISTANCE · BATTERY RUNTIME · POWER SOURCE
Edge endurance test. QNyx ran for 3.75 hours on a Raspberry Pi Zero 2 W powered by three AAA batteries, tunnelling roughly 15,500 km from Leamington, Ontario to Sydney, Australia — holding the 15-minute post-quantum rekey cadence until the batteries gave out.

Low-Power Edge Deployment

Post-quantum security that runs on three AAA batteries.

QNyx was built for hardware that does not have a rack, a fan, or a reliable power budget — sensors, vehicles, remote sites, field kit. The Pi Zero test is not a stunt; it is the design target.

3.75 h

Continuous runtime on a Raspberry Pi Zero 2 W powered by three AAA batteries, maintaining a 15,500 km post-quantum tunnel from Leamington, Ontario to Sydney, Australia.

  • Built for low-power hardware. The cryptographic path is efficient enough that a battery-powered single-board computer can hold an intercontinental tunnel for hours.
  • ARM64 and x64 Linux. From compact edge computers to conventional server hardware, with the same binary and the same feature set.
  • Android. The same transport runs on Android devices, so handhelds and mobile gateways join the same post-quantum network as fixed sites.
  • Unattended by design. Self-healing recovery and self-configuring addressing mean a deployed node needs no operator after install — which is the only workable model when the node is somewhere nobody is going to visit.
  • 1 MB of storage, no dependencies. Nothing to install alongside it and nothing to keep in sync.

Platform · Linux & Android · 100% Rust

One Rust binary, dropped anywhere Linux or Android runs.

QNyx 3.0.2 is written in 100% Rust and ships as a single 1 MB standalone executable. It attaches to the host through the standard TUN interface — no kernel module, no patched network stack, no runtime to install.

QNyx data path through the Linux TUN interface Traffic flows from an application through the Linux IP stack and the TUN device into QNyx, which sends post-quantum key exchange over TCP port 443 and encrypted data over a random high UDP port. HOST NETWORK APP ANY IP TRAFFIC KERNEL IP STACK TUN /dev/net/tun QNyx 1 MB · RUST MTU 1410 TCP / 443 ML-KEM KEY EXCHANGE UDP / HIGH ENCRYPTED DATA UNCHANGED UNCHANGED USERSPACE NO KERNEL MODULE · NO PATCHED STACK · LINUX ARM64 / x64 · ANDROID
Two channels, both outbound. Post-quantum key exchange runs over TCP/443, which is permitted outbound almost everywhere. The data channel uses a random high UDP port — the client-initiated flow creates the firewall state that return traffic rides back on.

Linux ARM64

From Raspberry Pi Zero and Pi 5 class boards up to ARM server infrastructure, using the standard TUN device.

/dev/net/tun

Linux x64

Conventional x64 Linux hardware and virtual machines, with no specialized networking platform required.

/dev/net/tun

Android

The same post-quantum transport on Android devices, bringing handhelds and mobile gateways onto the same tunnel fabric as fixed nodes.

arm64 · same protocol · same identity model

100% Rust, 1 MB, standalone

Memory-safe by construction and dependency-free in deployment. Copy one file to the host and run it.

qnyx -c <server_ip> -pr client.priv -pu server.pub

Security Model

Designed for data that has to stay protected past the quantum horizon.

QNyx approaches network security as a transport problem: establish authenticated post-quantum sessions, protect the traffic, and keep refreshing session material while the tunnel stays up — including after every self-healed reconnect.

QNyx post-quantum rekey cycle Every 900 seconds a new ML-KEM-1024 handshake runs in the background while traffic continues on the current key, then the new key is installed with no dropped packets. SESSION LIFECYCLE TRAFFIC FLOWING ON KEY K₁ FLOWING ON KEY K₂ BACKGROUND ML-KEM-1024 KEX t = 0 SESSION UP TRIGGER IN-TUNNEL TOKEN t = 900 s K₂ INSTALLED REPEATS EVERY 15 MINUTES · ML-DSA-65 VERIFIED BOTH ENDS 0 PACKETS DROPPED
Continuous verification is not a policy setting. The tunnel re-runs the full post-quantum handshake four times an hour, on the same code path as the initial connection and the same one used to recover a dead link, while traffic keeps flowing on the current key.
  • Key Encapsulation

    ML-KEM-1024 (FIPS 203) establishes protected session material for every handshake, rekey and recovery.

  • Identity

    ML-DSA-65 (FIPS 204) keypairs are the only form of identity. A server trusts exactly the public keys in its approved directory — no passwords, no accounts, no shared secrets.

  • Payload

    HF8 + AES-GCM protects tunnel traffic with authenticated encryption and 57 bytes of fixed overhead.

  • Rekeying

    Session material refreshes automatically every 900 seconds with no operator involvement and no dropped packets.

  • Wire Image

    No plaintext protocol headers. A QNyx packet is a UDP datagram carrying a uniformly distributed blob — there is nothing to parse or fingerprint.

  • Revocation

    Delete a public key from the approved directory and the client is out at its next handshake. The directory is re-read on every incoming connection.

Documentation

Everything an operator needs, in one document.

The QNyx 3.0.2 Operator's Manual is the operational guide for the current production release: installation, identity enrolment, command syntax, firewall requirements, and a complete log message reference. Written for network technicians comfortable with the Linux CLI.

Current Release

QNyx V3.0.2 Operator's Manual

Day-to-day deployment, configuration, and maintenance of QNyx endpoints. Not a cryptographic reference or protocol specification.

PDF QNyx v3.0.2 August 2026 Linux
Download Manual
  • Installation Requirements, identity generation, key enrolment
  • Command Reference Server, client, and keygen flags with defaults
  • Network Requirements TCP KEX and UDP data channel, NAT and MTU notes
  • Log Reference Every message, its severity, and the action to take

Frequently Asked Questions

QNyx, post-quantum transport, and Xaoc Industries.

What is QNyx?
QNyx is a post-quantum native transport protocol built by Xaoc Industries in Canada. It behaves like a VPN — it carries ordinary IP traffic through an encrypted tunnel — but every layer of it, including key exchange and identity, is post-quantum from the start rather than retrofitted onto classical cryptography.
Which post-quantum algorithms does QNyx use?
ML-KEM-1024 (FIPS 203) for key encapsulation and ML-DSA-65 (FIPS 204) for digital signatures and node identity. Tunnel payloads are protected with HF8 and AES-GCM authenticated encryption, and session keys rotate every 900 seconds.
How fast does QNyx recover from a dropped link?
Under 60 seconds. A missed heartbeat marks the peer dead at 15 seconds, and the node immediately re-runs the ML-KEM-1024 key exchange and restores the tunnel on the same addresses. No operator action, no watchdog script, no monitoring system in the loop.
Do I have to configure IP addresses for a QNyx tunnel?
No. QNyx assigns tunnel addressing itself and binds each address to the peer's ML-DSA-65 public key, so a node keeps the same tunnel IP across reconnects, reboots and changes of underlying network. Adding a client means dropping its public key file into the server's approved-keys directory; revoking one means deleting it.
What hardware and operating systems does QNyx run on?
Linux on ARM64 and x64, plus Android. The same 1 MB binary runs unmodified from a battery-powered Raspberry Pi Zero 2 W up to multi-gigabit routers, using the standard TUN interface with no kernel module and no patched network stack.
How fast is QNyx?
QNyx saturates 1 Gbps Ethernet on a Raspberry Pi 5 and reaches 1100 Mbps in-tunnel on 2.5 GbE hardware. Added latency is under 1 millisecond, and fixed protocol overhead is 57 bytes per packet.
Is QNyx written in Rust?
Yes — 100% Rust, shipped as a single 1 MB standalone binary with no runtime, no interpreter and no external libraries to install.
How is QNyx different from a traditional VPN?
Three ways. It is post-quantum native, with no classical fallback to negotiate down to. It is self-healing, treating link loss as a protocol event resolved in under a minute rather than an incident for an operator. And it is self-configuring, deriving addressing from cryptographic identity instead of an IP plan someone has to maintain.
Who makes QNyx?
Xaoc Industries Inc., a post-quantum networking company based in Ontario, Canada. Write to info@xaocindustries.com to discuss a pilot deployment.

Xaoc Industries · Canada

The network can fail. Your encryption shouldn't.

Xaoc Industries builds post-quantum networking technology in Canada for systems that cannot assume perfect connectivity or a nearby operator. QNyx 3.0.2 is the current expression of that idea: post-quantum native, self-healing, self-configuring, 1 MB of Rust, and fast enough to disappear into the path.

Request a Pilot Contact Xaoc Industries Operator's Manual