Security

Security design and limitations

This page describes boundaries users can verify today and trust work that remains unfinished.

Mandatory hybrid post-quantum security

RatelMesh restricts TLS 1.3 to X25519MLKEM768 and derives a WireGuard preshared key from an ML-KEM-768 shared secret. ML-KEM encapsulation is authenticated with ML-DSA-65; invalid signatures, key mismatches, and missing or invalid post-quantum sessions fail closed.

WireGuard still includes Curve25519, so this is a hybrid design—not a claim that every system component is purely post-quantum.

Keys and control plane

WireGuard private keys are generated and remain on the device. The control plane receives public keys and distributes signed network state; authorization signatures bind node identity and routes.

A compromised control plane could still revoke devices or deny service; client verification reduces risk but is not zero trust.

What relays can see

Tenant-owned RELAY nodes forward WireGuard ciphertext. They cannot decrypt tunnel content, but can observe endpoints, timing, packet sizes and traffic volume.

Identity and access

The beta uses email verification and short-lived one-use enrollment codes. Enterprise SSO, passkeys and multi-factor device approval remain future work.

Kill-switch boundaries

Exit mode takes over IPv4, IPv6 and DNS and blocks local fallback when the route fails. Platform behavior still requires continuous real-device testing.

Download verification

SHA-256 detects transfer corruption. Windows Authenticode, the iOS App Store release and the RatelMesh-signed Android direct release are live; macOS notarization, Google Play distribution and an independent security audit are not complete.

Report a vulnerability

Send reproducible steps, affected versions and impact to admin@ratelmesh.com. Never send live credentials or private keys. admin@ratelmesh.com