EntropyMessenger

High-performance, zero-knowledge messaging engineered for total privacy.

Comment

Project Story: Entropy

Inspiration

Modern messaging platforms frequently trade privacy and performance for centralized control. Centralized message brokers collect metadata, create single points of failure, and struggle to scale under high-concurrency spam attacks without intrusive user identification like phone numbers or third-party CAPTCHAs.

Entropy was built to solve this: an asynchronous, zero-knowledge real-time messaging architecture designed to scale deterministically using Rust and cryptographically deter spam without compromising user anonymity.

Technical Architecture and Implementation

Entropy is engineered from the ground up to prioritize minimal latency, memory safety, and cryptographic integrity.

Core Tech Stack

  • Engine / Backend: Rust (tokio, axum, dashmap, axum-extra)
  • State & Caching: Redis (redis-rs async connection pools)
  • Cryptographic Primitives: ed25519-dalek, curve25519-dalek, sha2, argon2, num-bigint
  • Frontend / Web Client: Modern TypeScript & WebSockets

Key Features

  1. Dynamic Adaptive Proof-of-Work (PoW) & Verifiable Delay Functions (VDF): To prevent DDoS attacks and spamming without sacrificing user anonymity, Entropy uses dynamic computational friction applied at the transport layer.

  2. High-Concurrency Relay Layer: Leveraging Rust's async runtime (tokio) and lock-free concurrent state (DashMap), the backend routes encrypted payloads over WebSockets with minimal allocation overhead.

  3. Zero-Knowledge Handshakes: Connections establish ephemeral session keys using Curve25519 DH key exchange prior to payload transmission.

Cryptographic and Mathematical Foundations

1. Dynamic Spam Resistance (PoW Difficulty)

Entropy dynamically scales the required difficulty $D$ based on active connection load $C$ and client penalty multipliers $M_p$:

$$D_{\text{base}} = \begin{cases} 10 \cdot B & \text{if } C > 10000 \ 6 \cdot B & \text{if } C > 5000 \ 4 \cdot B & \text{if } C > 1000 \ 2 \cdot B & \text{if } C > 500 \ B & \text{otherwise} \end{cases}$$

$$D_{\text{effective}} = \min\left( D_{\text{base}} \times M_p, \; D_{\text{max}} \right)$$

2. Time-Lock Puzzle and VDF Verification

To verify computationally heavy work efficiently in $O(\log T)$ time on the server, Entropy utilizes the Wesolowski / Pietrzak RSA-group VDF mechanism:

  • Prover (Client): Computes $y = x^{2^T} \pmod N$ via sequential squaring (taking time proportional to $T = D_{\text{effective}}$).
  • Verifier (Server): Given secret order $\phi(N)$, computes shortcut exponent $e$:

$$e = 2^T \pmod{\phi(N)}$$

The server verifies the claimed result $y_{\text{claimed}}$ in a single exponentiation step:

$$y_{\text{expected}} \equiv x^e \pmod N \quad \implies \quad y_{\text{claimed}} \stackrel{?}{=} y_{\text{expected}}$$

Engineering Challenges

  1. VDF Verification Overhead vs. Arbitrary Precision Arithmetic: Evaluating $x^{2^T} \pmod N$ securely in Rust required strict constant-time primitives and high-efficiency big integer operations (num-bigint). Benchmarking and tuning bigint modular exponentiations were critical to preventing verifier CPU saturation under heavy load.

  2. Managing Dynamic WebSocket State: Synchronizing ephemeral client sessions across worker threads without introducing global mutex contention required migrating traditional shared states to lock-free concurrency patterns (DashMap and atomic reference counting).

  3. Zero-Storage Relay Guarantees: Ensuring that no persistent unencrypted payloads ever touch disk storage required building strict in-memory pub-sub channels with automatic TTL decay in Redis.

Key Learnings

  • Rust for High-Concurrency Systems: Building real-time WebSocket relays in Rust reinforced the control and predictability provided by tokio's cooperative task scheduling and strict memory safety guarantees under extreme concurrency.
  • Cryptographic UX Balance: Proof-of-work, when paired with fast verification schemes like VDFs, serves as an effective and privacy-preserving alternative to traditional CAPTCHAs and IP-based rate limiting.
  • Modular Architecture: Maintaining absolute separation of concerns between message validation, telemetry, and network routing layers proved vital for debugging and ongoing optimizations.

Built With

Share this project:

Updates

Submission history