Skip to main content

Zeq VPN — serverless mathematical tunnels

Zeq VPN connects two peers directly, with no central server in the path and no signature database anywhere. You pick a peer, open a tunnel, and every packet is wrapped in AES-256-GCM. The part that makes it Zeq is how the key comes to exist: it's derived mathematically, on the clock, brokered by state machines rather than handed out by a server.

The key is derived, not exchanged​

Two machines that already share a deterministic identity and a synchronised clock don't need an asymmetric key exchange. The tunnel key is an HMAC over both peers, a nonce, and the Zeqond:

K=HMAC(mesh secret, A∥B∥nonce∥zeqond)  →  AES-256-GCM,  IV=zeqond∥counterK = \mathrm{HMAC}\bigl(\text{mesh secret},\ A \parallel B \parallel \text{nonce} \parallel \text{zeqond}\bigr) \;\rightarrow\; \text{AES-256-GCM},\ \ IV = \text{zeqond} \parallel \text{counter}

The state machines broker the handshake, the derived shared key is stored in the ZSC, and the Zeqond is woven into the IV of every packet — so the encryption is bound to the framework's clock, packet by packet. No central server ever holds a key or sees the traffic.

Pick a peer, open a tunnel​

Serverless

Tunnels are peer-to-peer. There's no VPN server to trust, breach, or subpoena — the brokers are state machines, the key lives in your ZSC.

Peer marketplace

Choose a peer to tunnel through from the marketplace; usage is metered in credits.

On the pulse

The tunnel's composite is reported at 1.287 Hz, and each packet's IV carries the Zeqond — encryption synchronised to the clock.

Open it​

Open Zeq VPN →

Pick a peer and open a mathematical tunnel.
  • HITE encryption — the framework's clock-bound encryption.
  • ZSC — where the tunnel's shared key is stored.
  • The economy — how tunnel usage is metered.