COSINIUM

Post-Quantum VPN

QuicN

The QUIC-based Post-Quantum VPN protocol that enables the Cosineq architecture. High performance and small enough to live in a container.

On a 4 vCPU instance with a ConnectX-5 SR-IOV NIC, QuicN delivers 24% more traffic than wireguard-go and 22% more than kernel WireGuard, using 96 MB of memory against wireguard-go's 431 MB.

Single TCP flow, hands-off, both directions, identical kernels both ends. 12 August 2026. On a large multi-core host the throughput ordering changes; see Performance.

What it is

The protocol that is the driver for Cosineq, designed and developed by Cosinium. Based on QUIC and TLS 1.3, with mandatory post-quantum key exchange at every point in the architecture, including on networks that choose a classical identity algorithm.

Algorithms

RoleAlgorithmNotes
Key exchange, every handshakeX25519MLKEM768Mandatory post-quantum hybrid X25519 + ML-KEM-768 (FIPS 203) with no classical-only encryption algorithms offered.
Identity signature, defaultML-DSA-44Self-created X.509, pinned by the SHA-256 of its SubjectPublicKeyInfo (SPKI). No CA and no chain in the certificate.
Identity signature, opt-inEd25519A classical algorithm you can choose for your network, but only deliberately, because it is not post-quantum safe. Available for interoperability or low-power devices.
Control-plane trust rootML-DSA-44Always enforced on controllers, relays, STUN servers and rendezvous tickets; they stay post-quantum even on an Ed25519 network.
Data planeAES-256-GCMOnly two TLS 1.3 cipher suites are accepted and anything else closes the connection. AES is chosen because any reasonable device has built-in hardware instructions that make it fast and efficient.

Session confidentiality post-quantum everywhere with hybrid key exchange as a mandatory on every network. Ed25519 is offered any only for relaxingpeer identity authentication, but the trust root stays post-quantum regardless.

Topologies

How a connection actually gets made

In every case the encrypted overlay is a layer riding over the network you already have. These diagrams show it as a session floating above the physical path.

Direct device to deviceOVERLAYPHYSICALone QUIC connection · inner IP in DATAGRAM framesX25519MLKEM768 · ML-DSA-44 · AES-256-GCMthe internet, as it already isDevice ADevice B
Direct device to deviceOVERLAYPHYSICALthe internet,as it already isDevice ADevice Bone QUIC connection · X25519MLKEM768 · ML-DSA-44
Direct device to device. One QUIC connection per peer pair, mutually pinned by their public keys. Each device can connect to and receive connections from other devices. This is the setup for users who have full control over letting devices reach each other directly, within their own network or across firewalls. The session continues even when the initiating device migrates.
Hole-punched through NATOVERLAYPHYSICALdirect session after STUN discoveryQUIC Initials sent simultaneouslyquicn-stunsignalling only, no trafficNAT on both sidesDevice ADevice B
Hole-punched through NATOVERLAYPHYSICALquicn-stunsignalling only, no traffic crosses itDevice ADevice BNAT both sides · both fire QUIC Initials after STUN
Hole-punched through NAT. Each side learns its own public address from an authenticated STUN server, the controller hands both peers the other's candidate addresses, and both punch a hole through their firewall to let the peer in. STUN is a side-channel for signalling to assist with establishing a connection between the peers and not involved with data traffic.
Relayed - when nothing else worksINNER SESSIONOUTER SESSIONSkeys negotiated end to end, unbroken through the relaythe relay forwards packets between the peersquicn-relayouter QUICouter QUICDevice ADevice B
Relayed - when nothing else worksINNER SESSIONOUTER SESSIONSouter QUICouter QUICDevice Aquicn-relayDevice Bforwards by token, never sees inner cleartext
Relayed - when nothing else works. Two layers: each device holds an outer QUIC session to the relay, and the inner session's keys stay between the two peers. The relay acts as a forwarder that only wraps the peers' traffic in a lightweight header. Both peers keep punching in the background and migrate to a direct path the moment one opens up.
Into an unprivileged containerOVERLAYQUIC DATAGRAMRemote peerunprivileged container: no tun, no admin-captransparent proxyegress dispatcherreplies go straight back into the peer’sQUIC session and not kernel routedLAN app
Into an unprivileged containerOVERLAYRemote peerunprivileged container, no tuntransparent proxyegress dispatcherLAN appreplies return into the peer’s QUIC session
Into an unprivileged container. Userstack-only mode has no tunnel device and needs no elevated capability. Inbound packets are handled entirely in userspace and replies return straight into the originating peer's QUIC session without touching kernel routing. The use case is container-based connectivity to its own services or to others on its LAN.
Out from a local applicationOVERLAYLocal appquicn127.0.0.1:1080synthesised overlay packetspeeregress terminatorServerThe egress peer cannot tell this apart from any other flow. No ICMP on this path.
Out from a local applicationOVERLAYLocal appquicn127.0.0.1:1080synthesised overlay packets,no ICMP on this pathpeeregress terminatorServerindistinguishable to the egress peer from any other flow
Out from a local application. An application connects to QuicN's SOCKS5 service (opt-in) and has its traffic delivered to the right peer. Both UDP and TCP are supported.

Why it is fast

All without a kernel module, DPDK, hugepages, dedicated cores or a modified kernel.

Minimising OS system calls and carrying dozens of packets
Uses all the network packet offloads available to userspace from the kernel to move as many packets across the network stack as efficiently as possible.
Tuned algorithms to attain crypto performance
Dedicated workers that process the packets efficiently, without eating up all CPU resources. The choices of algorithms is deliberate to keep the other CPU cores available for system use. Memory usage is also tuned to match the host platform so that it stays flat while transferring at high speed, even when under pressure.
Keeping it quiet when it should
All traffic processing is event-based without endless loops, so the CPU stays idle when nothing is happening - there is no polling core burning power just to wait.

Capabilities built into the protocol

Access inspection on every packet
A compiled per-peer filter enforced on both egress and ingress, and swappable atomically without tearing the session down. The 12.3 Gbit/s figure was measured with ACLs, source validation and telemetry all on.
Secure STUN
Unlike RFC 5389, the client's message is never sent in the clear. It comes back encrypted under a per-device key.
A protocol you could implement from specification
It's all UDP QUIC based. Three easily parsable control messages on one stream, and everything else is one data-plane format.
Fail closed with no weaker path
Failures such as a missing post-quantum group, a key mismatch, an unknown cipher or an unknown protocol version all close the VPN connection, rather than falling back to anything weaker.
Community edition

quicn-rs: a baseline open implementation

quicn-rs is a minimal peer-to-peer build of the protocol in Rust that works on Linux, macOS and Windows. We developed it to show that the protocol is open and to act as an independent conformance check against our high-performance reference implementation. Stay tuned - we'll be sharing it in our public git repository.

Elsewhere in the platform