Skip to content

Cryptography

R-VPN uses modern cryptographic primitives to ensure security and privacy.

Cryptographic Stack

Layer Algorithm Purpose
Key Agreement X3DH Authenticated key exchange
Message Encryption Double Ratchet Forward secrecy
Symmetric Cipher ChaCha20-Poly1305 Data encryption
Hashing SHA-256 Key derivation
Signatures Ed25519 Identity authentication

Key Agreement (X3DH)

The Extended Triple Diffie-Hellman (X3DH) protocol provides authenticated key exchange.

Process

  1. Client retrieves server's prekey bundle via HTTPS
  2. Client generates ephemeral key pair
  3. Both parties compute shared secrets:
  4. DH1 = Identity Key (client) × Signed Prekey (server)
  5. DH2 = Ephemeral Key (client) × Identity Key (server)
  6. DH3 = Ephemeral Key (client) × Signed Prekey (server)
  7. DH4 = Ephemeral Key (client) × One-Time Prekey (server)
  8. Shared secret derived via HKDF

Security Properties

  • Forward Secrecy - Compromise of long-term keys doesn't reveal past sessions
  • Authentication - Server identity verified via signed prekey
  • Deniability - No persistent keys required for communication

Double Ratchet

After X3DH, the Double Ratchet algorithm provides continuous key evolution.

Symmetric Ratchet

Each message uses a unique key derived from a chain key:

message_key, chain_key = HKDF(chain_key, message_number)

This provides forward secrecy - compromising a message key doesn't reveal past keys.

DH Ratchet

Periodically, a new Diffie-Hellman key pair is generated:

new_shared = DH(our_private, their_public)
root_key, chain_key = HKDF(new_shared)

This provides post-compromise security - if a key is compromised, future keys are still secure.

Data Encryption

ChaCha20-Poly1305

All data is encrypted using ChaCha20-Poly1305:

  • ChaCha20 - Stream cipher by Daniel Bernstein
  • Poly1305 - Message authentication code
  • Combined as AEAD (Authenticated Encryption with Associated Data)

Why ChaCha20-Poly1305?

Property ChaCha20-Poly1305 AES-GCM
Speed (no HW) Fast Slow
Side-channel Naturally constant-time Requires care
Mobile Low power Higher power
TLS 1.3 Mandatory Mandatory

Key Management

Identity Keys

  • Type: Ed25519 (signing), X25519 (DH)
  • Lifetime: Long-term (months to years)
  • Storage: Secure file system, hardware tokens recommended

Signed Prekeys

  • Type: X25519
  • Lifetime: ~1 week
  • Rotation: Automatic
  • Signature: Ed25519 by identity key

One-Time Prekeys

  • Type: X25519
  • Lifetime: Single use
  • Pool: 100 pre-generated keys
  • Purpose: Provides additional forward secrecy

Key Derivation

HKDF (HMAC-based Key Derivation Function) is used throughout:

// Root key from X3DH
root_key = HKDF(salt, ikm, "R-VPN-v1 X3DH", 32)

// Message keys
message_key = HKDF(chain_key, "R-VPN-v1 Message", 32)

Threat Mitigation

Threat Mitigation
Traffic Analysis TLS 1.3, WebSocket masking
Replay Attacks Nonces, sequence numbers
MITM X3DH authentication
Key Compromise Double Ratchet
Quantum Post-quantum hybrid mode (future)

Implementation

All crypto is implemented in Rust using well-audited libraries:

  • ring - Low-level crypto primitives
  • x25519-dalek - X25519 DH
  • ed25519-dalek - Ed25519 signatures
  • chacha20poly1305 - AEAD cipher
  • hkdf - Key derivation

Best Practices

  1. Keep keys secure - Use file permissions, encryption
  2. Rotate regularly - Prekeys rotate weekly
  3. Verify signatures - Always verify server keys
  4. Use strong TLS - TLS 1.3 only
  5. Monitor for anomalies - Unusual traffic patterns

Next Steps