Mixnet & Cover Traffic

Defeating timing analysis, one shuffled batch at a time.

The Timing Problem

Tor hides your IP address. Sealed sender hides your identity. Padding hides your message length. But none of these protect against timing analysis.

If an adversary observes that Alice sends an encrypted message at 14:32:07.123 and Bob receives an encrypted message at 14:32:07.892, the correlation is obvious even without decrypting either message. Over many messages, timing correlation becomes statistically certain.

Timing correlation attack:

  Observer at Alice's ISP:       Observer at Bob's ISP:
  14:32:07.123  Alice sends      14:32:07.892  Bob receives
  14:32:45.001  Alice sends      14:32:45.734  Bob receives
  14:33:12.505  Alice sends      14:33:13.201  Bob receives
  ...                            ...

  Statistical correlation: > 99.99% probability Alice is
  messaging Bob, even without any content decryption.

RVNT addresses this with two complementary mechanisms: mixnet-style batching and continuous cover traffic.

Standard Privacy Mode

In standard mode, RVNT prioritizes usability with modest timing protection:

Standard mode behavior:
  - Messages sent immediately (no batching delay)
  - Cover traffic: 1 dummy message per 30-60 seconds (random interval)
  - Cover traffic is encrypted, padded, and indistinguishable from real messages
  - Fixed-size padding applied to all messages (real and cover)

Timing protection level: MODERATE
  - Defeats casual observation
  - Does NOT defeat a determined adversary with continuous monitoring
  - Suitable for most users

Maximum Privacy Mode

In maximum privacy mode, RVNT implements full mixnet-style batching with cover traffic, at the cost of increased latency.

Batch Shuffling

Batch processing pipeline:

  1. ACCUMULATE
     - Messages queued during batch window
     - Batch window: random(500ms, 2000ms)
     - Window duration varies per batch (unpredictable)

  2. INJECT COVER TRAFFIC
     - Add 1-3 dummy messages to each batch
     - Dummy messages are full sealed sender envelopes
     - Addressed to self (silently discarded on receipt)
     - Indistinguishable from real messages in size and format

  3. SHUFFLE
     - Fisher-Yates shuffle of all messages in batch
     - Order of transmission is randomized
     - An observer cannot determine which message was queued first

  4. TRANSMIT
     - Send messages one at a time
     - Random inter-message delay: 50ms-200ms
     - Each message uses a different Tor circuit (if available)

  5. REPEAT
     - Next batch window starts immediately
     - Window duration re-randomized

Example batch:
  Queue: [msg_to_Bob, msg_to_Carol]
  Inject: [cover_1, cover_2]
  Shuffle: [cover_2, msg_to_Carol, cover_1, msg_to_Bob]
  Transmit with random delays between each

Random Delays

Delay distribution: truncated exponential

  delay = min(max_delay, -mean * ln(random()))

  Parameters:
    mean:      200ms
    max_delay: 2000ms

  Distribution properties:
    - Most delays are short (~200ms)
    - Some delays are long (~1-2 seconds)
    - Distribution matches natural network jitter
    - Attacker cannot distinguish intentional delay from network latency

  Applied at two levels:
    1. Between messages within a batch (50-200ms)
    2. Between batches (500-2000ms batch window)

Cover Traffic

Cover traffic in maximum privacy mode:

  Idle (no real messages to send):
    - 1 dummy message every 15-30 seconds (random interval)
    - Maintains constant traffic flow
    - Observer sees continuous activity regardless of real messaging

  Active (real messages being sent):
    - 1-3 dummy messages per batch (in addition to real messages)
    - Dummy/real ratio varies randomly
    - Observer cannot distinguish batches with real messages
      from batches with only cover traffic

Cover message construction:
  1. Generate random 256-byte payload
  2. Encrypt with a throwaway Double Ratchet session (to self)
  3. Wrap in sealed sender envelope (recipient = self)
  4. Pad to standard fixed size
  5. Result is byte-for-byte indistinguishable from a real message

Cover message receipt:
  1. Receive envelope
  2. Unseal: recipient_id matches self
  3. Detect cover traffic flag in decrypted payload
  4. Silently discard
  5. No UI notification, no storage, no logging

Mode Comparison

Threat Analysis

What the Mixnet Defeats

• Simple timing correlation: The random delays and batch shuffling break the 1:1 correlation between send and receive times.
• Volume analysis: Cover traffic maintains constant volume regardless of real messaging activity.
• Burst detection: Batch injection smooths activity patterns. A burst of 5 real messages looks like a burst of 5-8 messages (real + cover).
• Idle/active detection: Cover traffic ensures the network sees activity even when the user is not messaging.

What the Mixnet Does NOT Defeat

• Global passive adversary (GPA): An entity observing all internet traffic simultaneously can correlate over long time periods despite delays. Statistical methods over hundreds of messages can overcome the noise. This is a fundamental limitation of low-latency mixnets.
• Long-term statistical analysis: Given enough messages (hundreds to thousands), even with random delays, an adversary can build a probabilistic model of communication partners.
• Intersection attacks: If Alice is consistently online when messages arrive for Bob, and offline when they do not, the adversary can narrow down candidates even without timing precision.

Battery and Bandwidth Policy

Cover traffic adapts to device state:

  Foreground (app active):
    Standard:  1 cover msg / 30-60s
    Max priv:  1 cover msg / 15-30s

  Background (app inactive):
    Standard:  1 cover msg / 2-5 min  (reduced)
    Max priv:  1 cover msg / 30-60s   (reduced)

  Low battery (< 20%):
    Standard:  Cover traffic suspended
    Max priv:  1 cover msg / 2-5 min  (heavily reduced)

  WiFi vs Cellular:
    WiFi:      Full cover traffic rate
    Cellular:  Reduced by 50% (save data)

Further Reading

• Tor Integration -- The anonymity network that mixnet batching runs on top of
• Sealed Sender -- Hiding sender identity from the network
• Threat Model -- What RVNT protects against and known limitations