Secure Transport Layer

Privacy is not a policy.
It is mathematics.

A zero-trust messaging protocol where the server is mathematically incapable of accessing message content. Strategically hosted in Hong Kong to ensure data sovereignty.

Read Whitepaper
X3DH + Double Ratchet Key Agreement
CRYSTALS-Kyber768 Post-Quantum Hybrid
XChaCha20-Poly1305 AEAD Encryption
No Logs Blind Relay

01 / Architecture

The Server is a
Blind Relay.

Traditional "secure" messengers act as trusted intermediaries. RChat removes trust from the equation entirely. The server sees nothing but opaque, encrypted bytes.

ALICE KEY GEN
Blind Relay
Routing opaque packets.
No decryption keys.
BOB DECRYPT
ciphertext = XChaCha20Poly1305(key=k_ratchet, msg=plaintext)

01 / Key Generation

Strictly On-Device.

Private keys are generated on user hardware and never transmitted. The server possesses no cryptographic capability to decrypt payloads.

02 / Metadata

Zero Retention.

RChat utilizes opaque circuit identifiers to route packets. We do not maintain social graphs, timestamps, or sender-receiver logs.

03 / Transport

TLS 1.3 Tunneling.

All protocol traffic is encapsulated within standard HTTPS (TLS 1.3) frames, rendering it indistinguishable from standard web browsing.

02 / Jurisdiction

Strategic Independence.
Hong Kong Hosting.

Cryptography is only as strong as the legal jurisdiction holding the hardware. RChat infrastructure is legally domiciled and physically hosted in Hong Kong, placing it strictly outside the jurisdiction of Western intelligence sharing agreements.

DATA SOVEREIGNTY ASSURANCE We are not subject to National Security Letters from 5-Eyes nations.
5 EYES (US, UK, CAN, AUS, NZ) AVOIDED
9 EYES (+ FR, NL, DK, NO) AVOIDED
14 EYES (+ DE, BE, IT, SE, ES) AVOIDED
HONG KONG OFFSHORE ACTIVE

03 / Comparison

Verify the Difference.

FEATURE RCHAT SIGNAL TELEGRAM
Server Blind Relay YES NO NO
Post-Quantum (Kyber768) HYBRID PARTIAL NO
Jurisdiction HONG KONG USA (5 EYES) UAE
Self-Hostable YES DIFFICULT NO

04 / Ownership

Don't Trust Us.
Run Your Own Node.

True security requires the ability to verify the infrastructure. RChat is 100% open source. You can audit the code and deploy your own relay node in minutes using Docker.

VIEW GITHUB REPOSITORY
➜ git clone https://github.com/rchat/relay.git
➜ cd rchat-relay
➜ docker-compose up -d
[+] Running 3/3
⠿ Network rchat_net Created
⠿ Container rchat-db Started
⠿ Container rchat-api Started
➜
RChat Technical Documentation

End-to-End Encrypted
Messaging Protocol

VERSION 1.0
DATE FEB 2026
AUTH RCHAT SECURITY TEAM

Abstract

RChat is a secure messaging platform designed from the ground up for true end-to-end encryption (E2EE). Unlike existing solutions where service providers control key distribution, RChat employs a zero-trust architecture where the server is mathematically incapable of accessing message content.

Server-blind relay
Client-side key gen
Post-quantum hybrid
Verifiable security

01 / Introduction

1.1 Motivation

Existing messaging platforms (Signal, WhatsApp, Telegram) claim end-to-end encryption but retain capabilities that enable compromise: Key Control, Metadata Collection, and vulnerability to Legal Coercion.

RChat eliminates these vulnerabilities through architectural design rather than policy promises. Our design principles rely on Zero Server Trust, where the server is trusted only to route opaque packets, and Cryptographic Impossibility, ensuring server compromise cannot reveal plaintext.

1.2 Threat Model

Adversaries Considered:

  • Passive network eavesdroppers
  • Active man-in-the-middle attackers
  • Compromised server infrastructure
  • Nation-state actors with significant resources
  • Malicious client devices (post-compromise)

Security Goals:

Confidentiality Only intended recipients can read messages.
Integrity Messages cannot be modified undetected.
Forward Secrecy Past messages secure if keys compromised.
Future Secrecy Future messages secure after key compromise.

02 / Cryptographic Primitives

Core Algorithms

SYMMETRIC
XChaCha20-Poly1305

Large 192-bit nonce eliminates reuse concerns. AEAD guarantees. Faster than AES-GCM on mobile.

ASYMMETRIC
X25519 (ECDH)

Curve25519. High security with compact 32-byte keys. Widely deployed and vetted.

SIGNATURES
Ed25519

Compact 64-byte signatures. Fast verification. Deterministic and side-channel resistant.

HASHING & KDF
BLAKE3 & HKDF-SHA256

BLAKE3 for integrity/fingerprinting. HKDF-SHA256 for FIPS-compliant key derivation.

03 / Key Exchange Protocol

3.1 Extended Triple Diffie-Hellman (X3DH)

X3DH establishes initial shared secrets between parties who haven't previously communicated.

3.1.1 Key Bundle Structure

struct KeyBundle {
    // Long-term identity key (Ed25519)
    identity_key: Ed25519PublicKey,
    
    // Medium-term signed pre-key (X25519)
    signed_pre_key: X25519PublicKey,
    signed_pre_key_signature: Ed25519Signature,
    
    // Short-term one-time pre-keys (X25519)
    one_time_pre_keys: Vec,
}
3.1.2 Handshake Logic

The X3DH "Mixer"

ALICE (Initiator)
Inputs
Identity IK_A
Ephemeral EK_A
Computation
DH1 IK_A + SPK_B
DH2 EK_A + IK_B
DH3 EK_A + SPK_B
DH4 EK_A + OPK_B
SHARED SECRET (SK)
BOB (Offline)
Key Bundle
Identity IK_B
Signed Pre SPK_B
One-Time OPK_B

3.2 Post-Quantum Extension: CRYSTALS-Kyber

To protect against quantum computing threats, RChat implements a hybrid key exchange combining X25519 with CRYSTALS-Kyber768.

struct HybridKeyExchange {
    // Classical X25519
    x25519_public: X25519PublicKey,
    x25519_ephemeral: X25519PublicKey,
    
    // Post-quantum Kyber768
    kyber_public: Kyber768PublicKey,
    kyber_ciphertext: Option,
}

combined_ss = HKDF-SHA3-256(
    input_key_material = classical_ss || pq_shared_secret,
    salt = transcript_hash,
    info = "RChat Hybrid v1"
)

04 / Message Encryption

The Double Ratchet Algorithm

After X3DH, the Double Ratchet provides per-message unique encryption keys and self-healing properties.

KDF CHAIN STATE
Message Key Derivation
ROOT KEY
KDF
MSG 1
CHAIN KEY 1
KDF
MSG 2
CHAIN KEY 2

4.2 Key Derivation Functions (Rust)

fn kdf_rk(root_key: &[u8; 32], dh_out: &SharedSecret) -> ([u8; 32], [u8; 32]) {
    let hkdf = Hkdf::::new(Some(root_key), &dh_out.to_bytes());
    let mut okm = [0u8; 64];
    hkdf.expand(b"RChat ratchet", &mut okm).unwrap();
    
    let new_root_key: [u8; 32] = okm[0..32].try_into().unwrap();
    let chain_key: [u8; 32] = okm[32..64].try_into().unwrap();
    (new_root_key, chain_key)
}

05 / Transport Protocol

5.1 WebSocket over TLS 1.3

All communication occurs over a single WebSocket connection with mandatory TLS 1.3. This ensures Perfect Forward Secrecy by default and renders traffic indistinguishable from standard HTTPS web browsing.

5.2 Unified Frame Protocol

Wire Format

Relay Packet Structure

0
31
TYPE (0x01)
Reserved / Padding (24 bits)
CIRCUIT ID 128-bit Opaque Route Token (16 Bytes)
VER
FLAGS
Reserved
AUTH TAG HMAC-SHA256 (16 Bytes)
ENCRYPTED PAYLOAD Variable Length • XChaCha20-Poly1305
Header
Metadata
Integrity
Ciphertext

5.3 Server Role: The Opaque Relay

What Server KNOWS
  • IP addresses of connected clients
  • Timing of connections
  • Encrypted payload sizes (padded)
What Server CANNOT Know
  • Message content (Impossible)
  • Who talks to whom (Opaque IDs)
  • Any encryption keys

06 / Security Analysis

Theorem 1 (Message Confidentiality)

Assuming XChaCha20-Poly1305 is IND-CCA secure and the Double Ratchet maintains key indistinguishability, an adversary with full server compromise cannot determine message plaintext.

Theorem 2 (Forward Secrecy)

Compromise of long-term identity keys at time T does not compromise messages sent before T, as X3DH uses ephemeral keys.

Theorem 3 (Future Secrecy)

Compromise of session keys at time T does not compromise messages sent after T, provided the DH ratchet advances.

6.2 Attack Resistance

Attack Vector Resistance Mechanism
Passive Eavesdropping HIGH Full E2EE / TLS 1.3
Active MITM HIGH Key Fingerprint Verification
Server Compromise COMPLETE Zero-Knowledge Architecture
Quantum Decryption HYBRID Kyber768 Encapsulation

07 / Implementation Security

7.1 Constant-Time Operations

All cryptographic operations use constant-time implementations to prevent timing side-channels.

// Constant-time comparison
use subtle::ConstantTimeEq;
if signature.ct_eq(&expected).into() {
    // Valid
}

7.2 Memory Safety

  • Rust: Memory-safe language prevents buffer overflows.
  • Zeroization: Sensitive data cleared from memory immediately after use.
  • mlock: Key material locked in RAM (not swapped to disk).

08 / Platform Comparison

FEATURE RCHAT SIGNAL TELEGRAM
Server sees plaintext NO NO NO*
Server controls keys NO YES YES
Post-Quantum Crypto HYBRID NO NO
Metadata Storage NONE MINIMAL EXTENSIVE

* Telegram default chats are NOT end-to-end encrypted.

09 / Future Work

  • Full Kyber768 Integration: Complete migration to PQ primitives.
  • Decentralization: Peer-to-peer connection establishment and DHT for key discovery.
  • Mix-net Routing: Advanced metadata protection.

10 / Conclusion

RChat demonstrates that truly secure messaging is achievable through careful architectural design. By eliminating the server's ability to access keys or plaintext, we remove the largest attack surface in messaging systems.

Key Takeaway: Security through architectural impossibility is stronger than security through policy promises.

Appendix A: Parameters

A.1 Key Sizes

Identity Key32 bytes (Ed25519)
Signed Pre-Key32 bytes (X25519)
One-Time Key32 bytes (X25519)
Circuit Token32 bytes (HMAC)

A.3 Message Overhead

DH Header32 bytes
Message No.4 bytes
Poly1305 Tag16 bytes
Total Overhead56 bytes + Cipher