Security model
How VoidSend encryption works
VoidSend is an end-to-end encrypted messenger built so that the people running it cannot read what you send. This page explains, without hand-waving, what happens to a message between your device and your contact's, what the server stores, and which standards every step relies on.
The short version
- Your keys come from your passkey. Face ID, Touch ID, a fingerprint or your device PIN unlocks a passkey whose PRF output deterministically derives your encryption and signing keys. Nothing is uploaded, and every device you own derives the same keys.
- Every message gets its own key. A hybrid of X25519 and ML-KEM-768 agrees a fresh secret per message. Even if one of the two schemes is broken, the other still protects you.
- Content is sealed with AES-256-GCM and signed with ML-DSA-65, so tampering and forgery are detected before anything is shown to you.
- The relay is blind. It stores ciphertext for at most 30 days and forwards it. It never holds a decryption key.
The path of a message
- Key agreement. Your device generates a single-use X25519 key pair and encapsulates against your contact's ML-KEM-768 public key. Both operations yield a shared secret only the recipient's device can reconstruct.
- Hybrid combiner. The two secrets, the ephemeral public key, the ML-KEM ciphertext and both recipient public keys are fed into HKDF-SHA256 under a domain-separated salt. The result is one 256-bit message key bound to exactly the keys that produced it.
- Encryption. The message or file is encrypted with AES-256-GCM using a random 96-bit nonce. The 128-bit authentication tag means any modification is rejected before decryption.
- Signature. The message metadata is signed with your ML-DSA-65 key. The recipient verifies it locally against your public key, so neither the relay nor anyone else can forge a message from you.
- Relay. The server receives an opaque blob addressed to a username, keeps it until every device has collected it or 30 days pass, and forwards it over WebSocket.
- Decryption. The recipient's device recomputes the shared secret with its private keys, derives the same message key, checks the signature and tag, and only then decrypts.
You can see each of these layers on the home page, and read why the post-quantum half matters in post-quantum messaging explained.
The algorithms
| Layer | Algorithm | Standard | Role |
|---|---|---|---|
| Key agreement (classical) | X25519 | RFC 7748 | Elliptic-curve Diffie-Hellman with a fresh key per message |
| Key agreement (post-quantum) | ML-KEM-768 | NIST FIPS 203 | Lattice-based key encapsulation, security level 3 |
| Combiner | HKDF-SHA256 | RFC 5869 | Binds both secrets and the transcript into one message key |
| Content encryption | AES-256-GCM | NIST SP 800-38D | Authenticated encryption of every message and file |
| Signatures | ML-DSA-65 | NIST FIPS 204 | Post-quantum authenticity of message metadata |
| Sign-in | WebAuthn passkeys with PRF | W3C WebAuthn Level 3 | Phishing-resistant login and deterministic key derivation |
| Transport | TLS 1.3, WSS | RFC 8446 | Protects the encrypted blobs in transit to the relay |
| Calls | WebRTC DTLS-SRTP | RFC 5764 | Per-call media keys, relayed so peers never see each other's IP |
What the server stores
Because the relay is designed to be useless to an attacker, the list of what it holds is short.
| Data | Stored? | Notes |
|---|---|---|
| Username | Yes | Your chosen public handle |
| Public keys | Yes | X25519, ML-KEM-768 and ML-DSA-65 public keys so others can write to you |
| Encrypted messages and files | Yes, up to 30 days | Opaque ciphertext, removed when delivered and expired, or when you delete them |
| Who messaged whom, and when | Yes, with the ciphertext | Needed for delivery; removed with the message |
| Push notification token | Yes, if you enable notifications | From Apple, Google, Expo or your browser. Never contains message content |
| Message content | No | Encrypted on your device before upload |
| Private keys | No | Derived from your passkey and never transmitted |
| Phone number, email, contacts | No | Never requested |
| IP address in account data | No | Stored account data does not include it |
| Analytics or advertising identifiers | No | There are none |
Why passkeys
A password can be guessed, reused or phished. A passkey is a public-key credential bound to voidsend.xyz; a look-alike site cannot trigger it, and there is no secret to leak in a breach. VoidSend uses the WebAuthn PRF extension, which lets the authenticator return a stable secret only you can produce. That secret seeds your encryption and signing keys, which is how the web app, the iOS app and the Android app end up with the same identity without any key ever leaving your device. Read more in the FAQ.
Calls
Voice and video calls run on WebRTC with DTLS-SRTP, so each call negotiates its own media keys. Calls are relayed through VoidSend's TURN servers by default, which means the other participant never learns your IP address.
AI agents
Agents connect through the Model Context Protocol using the voidsend-mcp package. An agent has its own key bundle and encrypts and signs messages exactly as a human account does. Agent names carry the agent.prefix so you always know who you are talking to.
Independent review and source code
The full source code will be published once a third-party security audit is complete. Security researchers can reach us at security@analogmutations.com.