RVNT Protocol: A Technical Deep Dive
What This Post Covers
This is a detailed walkthrough of the RVNT cryptographic protocol — the decisions we made, the primitives we chose, and why. If you want to audit our claims, this is where to start.
The Handshake: Hybrid X3DH + ML-KEM-768
When two RVNT users first connect, they perform a key exchange based on the Extended Triple Diffie-Hellman (X3DH) protocol, extended with post-quantum ML-KEM-768.
The handshake produces a shared secret that both parties agree on, without ever transmitting it. An eavesdropper — even one with a quantum computer — cannot derive the shared secret from the public values exchanged.
Why Hybrid?
We combine X25519 (classical elliptic curve) with ML-KEM-768 (post-quantum lattice-based) because:
- X25519 is battle-tested, fast, and well-understood. If ML-KEM has an undiscovered flaw, X25519 still protects you.
- ML-KEM-768 is NIST FIPS 203 standardized and resistant to quantum attacks. If a quantum computer breaks X25519 in the future, ML-KEM still protects you.
- Hybrid means you get the stronger of the two. Both must be broken to compromise the session.
The Ratchet: Double Ratchet with AES-256-GCM
After the handshake establishes a shared secret, every message gets its own unique encryption key via the Double Ratchet algorithm (the same algorithm Signal uses).
Forward Secrecy
Each message key is derived from the previous one and then deleted. If an attacker compromises your device and extracts the current key, they cannot decrypt past messages — those keys no longer exist.
Break-in Recovery
The Diffie-Hellman ratchet periodically rotates the root key material. Even if an attacker learns a message key, future messages use new DH-derived keys that the attacker cannot predict.
Sealed Sender: Hiding Who Sent the Message
End-to-end encryption protects message content. But metadata — who sent a message to whom, when, and how often — can be just as revealing.
RVNT uses sealed sender to hide the sender’s identity from the network. The sender encrypts their identity inside the message envelope using the recipient’s public key. Only the recipient can unseal it.
Transport: Tor Integration
Messages route through the Tor anonymity network — a minimum of three relay hops. This prevents network observers from correlating sender and receiver by IP address.
Combined with sealed sender, neither the network nor any single relay can determine who is communicating with whom.
What We Don’t Claim
- We don’t claim to protect against a compromised device. If your phone has malware, no app can save you.
- We don’t claim to prevent screenshots or forwarding.
- We don’t claim quantum computers exist today. We prepare for them because responsible cryptography plans decades ahead.
Verify It Yourself
Every line of our cryptographic implementation is open source. Read the code, run the tests, break it if you can.