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