Threat Model

Every security tool has a threat model. If it does not publish one, it either does not have one or does not want you to see it. Here is ours.

Adversary Classes

RVNT's threat model considers the following adversary classes, ordered by capability:

Adversary	Capabilities	RVNT Defense
Passive network observer	Can observe encrypted traffic on the network	Tor routing, fixed-size padding, cover traffic
Compromised server operator	Full root access to all RVNT servers	Zero-knowledge architecture, sealed sender, no logs
Active network attacker (MITM)	Can intercept and modify network traffic	Authenticated encryption, key verification, Tor
Physical device seizure	Has physical possession of unlocked or locked device	Encrypted storage, PIN authentication, panic mode, duress PIN
Legal compulsion (targeting RVNT)	Subpoena, court order, national security letter	Cannot produce what we do not possess. Warrant canary.
Future quantum computer	Shor's algorithm against classical public-key crypto	Hybrid X25519 + ML-KEM-768 key exchange
Nation-state (targeted)	Endpoint compromise, targeted malware, human intelligence	Limited defense (see "What RVNT Does Not Protect Against")
Global passive adversary	Observes all internet traffic simultaneously	Partial defense only (see "Known Limitations")

What RVNT Protects Against

Server Compromise

If an attacker gains full control of every RVNT server, they obtain nothing useful. Servers never see message plaintext, sender identity, or encryption keys. They handle key exchange prekey bundles (which are public by design) and provide bootstrap nodes for peer discovery. A compromised server is a relay for public keys it was designed to distribute anyway.

Server compromise yields:
  ✓ Public key bundles (public by design, no secret)
  ✓ Usernames (public by design)
  ✓ Proof-of-work tokens (public registration data)
  ✗ Message content (never touches server)
  ✗ Message metadata (sealed sender)
  ✗ IP addresses (zero logging + Tor)
  ✗ Private keys (never leave device)
  ✗ Social graph (P2P discovery, no server knowledge)
  ✗ Conversation history (not stored on server)

Network Traffic Analysis

All client-server communication routes through the Tor anonymity network. The server never learns client IP addresses. An observer on the network sees Tor traffic but cannot determine who is messaging whom. Multiple layers of protection are applied:

Tor routing: Hides IP addresses (3-hop or 5-hop circuits)
Sealed sender: Hides sender identity from the network
Fixed-size padding: Prevents message length analysis
Cover traffic: Prevents idle/active detection
Mixnet batching: Defeats timing correlation (maximum privacy mode)

Future Quantum Computers

RVNT uses hybrid key exchange: X25519 (classical) combined with ML-KEM-768 (post-quantum, NIST Level 3). An attacker must break both to recover session keys. This protects against the "harvest now, decrypt later" attack: encrypted traffic captured today cannot be decrypted by future quantum computers.

Metadata Correlation

Sealed sender prevents the server from learning who sent a message. Cover traffic prevents timing analysis. Fixed-size padding prevents message length analysis. There is no social graph on the server because the server does not know who talks to whom. Even the recipient identifier visible to the network is a truncated hash, not the full public key.

Physical Device Seizure

Local storage is encrypted with SQLCipher (AES-256-CBC with HMAC-SHA256). Decryption requires the PIN-derived key (Argon2id, 64MB memory cost). Multiple defense layers:

Locked device: PIN required. Lockout escalation after failed attempts. Argon2id makes brute-force expensive.
Duress PIN: A secondary PIN that silently triggers panic mode and presents a decoy state.
Panic mode: Destroys all cryptographic material, including hardware-backed keys in the Secure Enclave.
Travel mode: Hides sensitive conversations behind a secondary authentication barrier.
Per-conversation lock: Individual conversations locked with separate PINs.

Legal Compulsion (Directed at RVNT)

A subpoena or court order served to RVNT yields:

What we can produce:
  - Public key bundles (already public)
  - Usernames (already public)
  - Server configuration (open source anyway)
  - Error count metrics (no identifying information)

What we CANNOT produce:
  - Message content (we never had it)
  - Sender/recipient pairs (sealed sender)
  - IP addresses (zero logging policy)
  - Private keys (we never had them)
  - Conversation history (stored only on user devices)
  - Metadata (we don't collect it)

We cannot hand over what we do not have.
This is architecture, not policy. Policy can change. Architecture cannot.

Compromised Message Keys

The Double Ratchet algorithm provides forward secrecy and break-in recovery. If an attacker obtains a message key, they can decrypt only the specific message encrypted with that key. Past and future messages use different keys. After the next DH ratchet step, the session heals automatically. See Forward Secrecy for the detailed mechanism.

Man-in-the-Middle During Key Exchange

X3DH provides implicit authentication through identity keys. Explicit authentication is provided by safety number verification. Users who verify safety numbers (via QR code scan or out-of-band comparison) are protected against MITM attacks during initial key exchange. Safety number changes trigger a prominent warning in the UI.

What RVNT Does Not Protect Against

Compromised Endpoint Device

If your operating system is compromised (malware, rootkit, spyware, state-sponsored implant), RVNT cannot protect you. The attacker can read messages from the screen buffer, capture keystrokes, extract keys from process memory, or intercept plaintext before encryption. Endpoint security is your responsibility. RVNT protects data in transit and at rest, not data on a compromised device.

This is the most important limitation. No messaging app can protect you if your device is compromised. Keep your operating system updated. Do not install software from untrusted sources. Use full-disk encryption. Enable automatic updates. Consider using a hardened OS (GrapheneOS, Qubes OS) if your threat model warrants it.

Shoulder Surfing

Someone looking at your screen can read your messages. RVNT does not protect against physical proximity attacks. Screen privacy filters and awareness of your surroundings are your defense.

Malicious Contacts

A contact can screenshot, forward, photograph, or memorize your messages. End-to-end encryption protects messages between you and your contact. It does not prevent your contact from sharing them. Trust your contacts or accept the risk.

Legal Orders Served to Your Contacts

If law enforcement serves a court order to the person you are messaging, that person may be compelled to hand over their device or produce messages. RVNT cannot prevent your contacts from being subject to legal process. Ephemeral messages can limit the window of exposure but do not eliminate it.

Rubber Hose Cryptanalysis

If an adversary uses physical coercion to compel you to reveal your PIN, RVNT's cryptographic protections are bypassed. The duress PIN feature provides limited defense: entering the duress PIN triggers panic mode while appearing to comply. However, a sophisticated adversary may detect the duress scenario (empty/decoy conversations, behavioral cues). Physical security is ultimately outside the scope of software.

Side-Channel Attacks

Timing side channels, power analysis, electromagnetic emanation, and cache-timing attacks are partially mitigated by constant-time implementations in the underlying cryptographic libraries (dalek, aes-gcm). However, RVNT has not undergone formal side-channel analysis, and implementation-level side channels may exist.

Known Limitations

Global Passive Adversary

A nation-state with the ability to observe all internet traffic simultaneously could theoretically perform traffic correlation attacks despite Tor. RVNT's cover traffic, padding, and mixnet batching increase the cost but do not guarantee defeat of such an adversary. This is a known limitation of all low-latency anonymity systems. The academic consensus is that low-latency anonymity networks cannot fully resist a global passive adversary.

ML-KEM-768 Maturity

ML-KEM-768 was standardized in August 2024 (FIPS 203). While extensively analyzed during the 7-year NIST standardization process, it has less deployment history than X25519 (which has been deployed since 2014). The hybrid approach mitigates this: even if a classical attack is found against ML-KEM, X25519 remains.

Double Ratchet Skip Limit

The 2000 message skip limit means that if more than 2000 messages are sent without acknowledgment, older skipped message keys are discarded and those messages become permanently undecryptable. This is a deliberate tradeoff to prevent denial-of-service attacks via the skipped key mechanism.

Offline Mesh Range

Offline mesh messaging (Bluetooth/WiFi Direct) is limited to device radio range (10-100 meters direct, multi-hop via relays). It is susceptible to proximity-based detection: an adversary can detect that RVNT mesh traffic is present in the area, even though they cannot read the content.

Key Verification Requirement

Key verification requires out-of-band comparison (QR code scanning or safety number comparison). Users who skip verification are vulnerable to MITM attacks during initial key exchange. RVNT warns users who have not verified contacts, but does not enforce verification.

Implementation Correctness

RVNT's security depends on the correctness of its implementation. Despite extensive testing (87%+ code coverage, 500M+ fuzz iterations, ProVerif models for core protocols), undiscovered bugs may exist. The code is open source and has not yet undergone a formal third-party security audit. We welcome and will fund external audits as resources permit.

Trust Boundaries


  ┌─────────────────────────────────────────────────────────┐
  │  TRUSTED (your device)                                 │
  │                                                         │
  │  ┌──────────────────────────────────────────────────┐  │
  │  │  RVNT Application                                │  │
  │  │  - Cryptographic operations                      │  │
  │  │  - Key storage (Secure Enclave)                  │  │
  │  │  - Encrypted database                            │  │
  │  │  - UI rendering                                  │  │
  │  └──────────────────────────────────────────────────┘  │
  │                                                         │
  │  ┌──────────────────────────────────────────────────┐  │
  │  │  Operating System                                │  │
  │  │  - Process isolation                             │  │
  │  │  - Memory protection                             │  │
  │  │  - Secure Enclave access control                 │  │
  │  │  ** If compromised, all bets are off **          │  │
  │  └──────────────────────────────────────────────────┘  │
  └─────────────────────────────────────────────────────────┘
                            │
                    TRUST BOUNDARY
                            │
  ┌─────────────────────────────────────────────────────────┐
  │  UNTRUSTED (network + infrastructure)                  │
  │                                                         │
  │  - RVNT identity server (sees only public keys)        │
  │  - Tor relays (sees only encrypted cells)              │
  │  - DHT nodes (sees only peer IDs)                      │
  │  - ISP (sees only Tor traffic)                         │
  │  - Adversary on network (sees nothing useful)          │
  └─────────────────────────────────────────────────────────┘

An honest threat model is more valuable than a marketing page that claims invulnerability.