diff --git a/docs/src/SUMMARY.md b/docs/src/SUMMARY.md index 818e9d9..9ca06af 100644 --- a/docs/src/SUMMARY.md +++ b/docs/src/SUMMARY.md @@ -9,6 +9,7 @@ - [How quicprochat Compares to WhatsApp, Telegram, and Signal](design-rationale/messenger-comparison.md) - [Comparison with Classical Chat Protocols](design-rationale/protocol-comparison.md) - [Why This Design, Not Signal/Matrix/...](design-rationale/why-not-signal.md) +- [Mesh Protocol Comparison: Reticulum, Meshtastic, Briar, Berty](design-rationale/mesh-protocol-comparison.md) --- diff --git a/docs/src/design-rationale/mesh-protocol-comparison.md b/docs/src/design-rationale/mesh-protocol-comparison.md new file mode 100644 index 0000000..43d330d --- /dev/null +++ b/docs/src/design-rationale/mesh-protocol-comparison.md @@ -0,0 +1,329 @@ +# Why QuicProChat for Mesh: Comparison with Reticulum, Meshtastic, Briar, and Berty + +This page compares QuicProChat's mesh networking approach against existing mesh/P2P messaging systems. The goal is to explain where QuicProChat fits, what it does better, and what trade-offs it makes. + +--- + +## At a Glance + +``` + Crypto Groups PQ-Ready Transport Maturity + ────── ────── ──────── ───────── ──────── +Meshtastic (LoRa) AES-CTR Shared No LoRa Mature + no PFS key only + +Reticulum X25519 None No Any Mature + PFS (links) + +Briar Double 1-hop No BT/WiFi Mature + Ratchet only + +Berty TBD TBD No IPFS/BLE Alpha + (Wesh) + +QuicProChat MLS+PQ Full Yes QUIC/LoRa Early + PFS+PCS groups /TCP/Serial +``` + +--- + +## The Fundamental Problem + +Existing mesh messengers make one of two compromises: + +1. **Good crypto, limited mesh** (Briar, Signal): Strong end-to-end encryption but limited to direct connections or one-hop relay. Messages don't traverse multi-hop mesh networks. + +2. **Good mesh, limited crypto** (Meshtastic, Reticulum): Transport-agnostic multi-hop routing but weak or absent group encryption. No post-compromise security. No post-quantum protection. + +**QuicProChat bridges this gap:** MLS group encryption with post-quantum hybrid KEMs, running over a Reticulum-inspired transport-agnostic mesh with multi-hop routing. + +--- + +## Detailed Comparison + +### Meshtastic + +Meshtastic is the dominant LoRa mesh platform with hundreds of thousands of nodes deployed worldwide. It optimizes for simplicity and interoperability over advanced cryptography. + +| Property | Meshtastic | QuicProChat | +|---|---|---| +| **Channel encryption** | AES-256-CTR with shared key | MLS per-epoch keys | +| **Forward secrecy** | None (same key forever) | Per-epoch key deletion | +| **Post-compromise security** | None | MLS Update heals the tree | +| **DM encryption** | PKC (X25519), recently added | MLS 1:1 or group DMs | +| **Key management** | Manual channel key sharing | Automatic MLS key agreement | +| **Post-quantum** | None | Hybrid X25519 + ML-KEM-768 | +| **Recent vulnerabilities** | CVE-2025-52464 (low-entropy keys), CVE-2025-53627 (DM downgrade) | Designed for auditability | + +**Meshtastic's crypto model:** + +``` +┌───────────────────────────────────────────────────────────────┐ +│ Meshtastic Channel │ +│ │ +│ All nodes share the same AES-256 key (e.g., "LongFast") │ +│ │ +│ Node A ── broadcasts ──► Node B ── relays ──► Node C │ +│ │ +│ Anyone with the channel key can: │ +│ • Read all messages (past and future) │ +│ • Inject messages (no sender authentication) │ +│ • Replay old messages │ +│ │ +└───────────────────────────────────────────────────────────────┘ +``` + +**QuicProChat's model:** + +``` +┌───────────────────────────────────────────────────────────────┐ +│ QuicProChat MLS Group │ +│ │ +│ Each epoch has a fresh group key derived from ratchet tree │ +│ │ +│ Node A ── encrypts ──► Node B ── relays ──► Node C │ +│ (MLS epoch key) (cannot read) (decrypts) │ +│ │ +│ • Relay nodes cannot read content │ +│ • Past epoch keys are deleted (forward secrecy) │ +│ • Any member can trigger re-key (post-compromise security) │ +│ • Hybrid KEM protects against quantum harvest-now attacks │ +│ │ +└───────────────────────────────────────────────────────────────┘ +``` + +**Why Meshtastic is still useful:** Mature, widely deployed, optimized for LoRa constraints. If your threat model doesn't require forward secrecy or post-quantum protection, Meshtastic is simpler to deploy. + +--- + +### Reticulum + +Reticulum is the closest architectural inspiration for QuicProChat's mesh layer. It pioneered transport-agnostic cryptographic networking over any medium. + +| Property | Reticulum | QuicProChat | +|---|---|---| +| **Language** | Python (CPython required) | Rust (cross-compile, no_std possible) | +| **Group encryption** | None (link-level only) | MLS RFC 9420 | +| **Crypto primitives** | X25519, Ed25519, AES, HMAC-SHA256 | Ed25519, X25519+ML-KEM-768, ChaCha20-Poly1305, MLS | +| **Post-quantum** | No | Yes (hybrid KEM) | +| **Forward secrecy** | Link-level only | End-to-end (MLS epochs) | +| **Post-compromise security** | No | Yes (MLS Update) | +| **Wire format** | msgpack | CBOR (IETF standard) | +| **Formal specification** | Reference implementation | Protobuf schemas, potential IETF draft | +| **Embedded targets** | No (requires CPython) | Yes (Rust cross-compile) | +| **Transport agnostic** | Yes (8 years mature) | Yes (Reticulum-inspired) | +| **Announce/discovery** | Mature | Implemented (S3 complete) | +| **Multi-hop routing** | Mature | In progress (S4) | + +**What QuicProChat takes from Reticulum:** + +- Announce-based self-organizing routing +- Transport-agnostic architecture +- Truncated hash-based addresses +- Lightweight handshake for constrained links +- Philosophy of "cryptography is mandatory, not optional" + +**What QuicProChat adds:** + +- End-to-end group encryption (MLS) instead of link-level only +- Post-quantum protection (hybrid KEM) +- Post-compromise security +- Rust implementation for embedded/resource-constrained targets +- IETF-standardized crypto (MLS RFC 9420) + +**Reticulum's link-level model:** + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ Reticulum Link │ +│ │ +│ A ──────── encrypted link ──────── B │ +│ (X25519 ephemeral per link) │ +│ │ +│ Multi-hop: │ +│ A ── link ── Relay1 ── link ── Relay2 ── link ── B │ +│ ▲ │ │ ▲ │ +│ └───────────┴───────────┴───────────┘ │ +│ Each relay can read and re-encrypt │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +**QuicProChat's end-to-end model:** + +``` +┌─────────────────────────────────────────────────────────────────┐ +│ QuicProChat Mesh │ +│ │ +│ A ══════════ MLS ciphertext ═══════════════ B │ +│ └─── transport ── Relay1 ── transport ── Relay2 ── transport ─┘ +│ (opaque) (opaque) │ +│ │ +│ Relays forward bytes but cannot decrypt content │ +│ (link encryption optional, defense in depth) │ +│ │ +└─────────────────────────────────────────────────────────────────┘ +``` + +--- + +### Briar + +Briar focuses on high-threat environments (protests, shutdowns) with strong cryptographic guarantees and censorship resistance via Tor. + +| Property | Briar | QuicProChat | +|---|---|---| +| **E2E encryption** | Double Ratchet (per-contact) | MLS (groups native) | +| **Group encryption** | Sender Keys | MLS ratchet tree | +| **Post-compromise security** | Groups: No | Groups: Yes | +| **Mesh topology** | One-hop social graph only | Multi-hop routing | +| **Transports** | Bluetooth, WiFi Direct, Tor | QUIC, TCP, LoRa, Serial | +| **Range** | 10-30m (BT) / 150m (WiFi) | LoRa: km-scale | +| **Battery** | 4x Signal (constant scanning) | Configurable announce interval | +| **Delay-tolerant** | Yes (store-and-forward) | Yes (MeshStore) | +| **Pairing required** | Yes (contact exchange) | Optional (announce discovery) | + +**Briar's design philosophy:** + +Briar prioritizes privacy over delivery rate. Messages only travel directly to the intended recipient—no hopping through mutual contacts. This maximizes privacy but limits range. + +**QuicProChat's approach:** + +Multi-hop routing like Reticulum, but with end-to-end MLS encryption. Relay nodes cannot read content. This enables km-scale LoRa mesh while maintaining cryptographic privacy. + +**Battery comparison:** + +``` +Briar: ████████████████████████████████ 4x baseline (constant BT scan) +Signal: ████████ baseline (server push) +QPC: ██████████ 1.2x baseline (configurable announce) +``` + +--- + +### Berty (Wesh Protocol) + +Berty uses IPFS/libp2p as its networking layer with a custom protocol (Wesh) for E2E encryption. + +| Property | Berty | QuicProChat | +|---|---|---| +| **Networking** | IPFS/libp2p | Custom (Reticulum-inspired) | +| **DHT** | IPFS Kademlia | Announce-based routing | +| **Message availability** | Depends on device online | Store-and-forward + server fallback | +| **Mobile** | React Native + gomobile-ipfs | Native SDKs (planned) | +| **Status** | Alpha, unaudited | Early development | + +**IPFS limitations for messaging:** + +- Content availability requires originating device online +- DHT lookups add latency (seconds to minutes) +- No timestamp authority for ordering +- Mobile resource constraints (IPFS daemon is heavy) + +QuicProChat avoids these by not relying on a global DHT. Routing is local (announce propagation) and message storage is explicit (MeshStore with TTL). + +--- + +## The QuicProChat Advantage: Layered Security + +Existing mesh protocols provide one or two layers of security. QuicProChat stacks three: + +``` + Meshtastic: Reticulum: QuicProChat: + ─────────── ────────── ─────────── + ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ + │ AES-256-CTR │ │ Link crypto │ │ Layer 3: Hybrid KEM │ + │ (shared key)│ │ (X25519/AES)│ │ (X25519 + ML-KEM) │ + └─────────────┘ └─────────────┘ ├─────────────────────┤ + │ Layer 2: MLS │ + │ (E2E group crypto) │ + ├─────────────────────┤ + │ Layer 1: Transport │ + │ (QUIC/TLS or link) │ + └─────────────────────┘ + + To decrypt: To decrypt: To decrypt: + • Channel key • Each link key • TLS + MLS epoch key + • At each hop + hybrid KEM + (3 independent layers) +``` + +--- + +## When to Choose Each System + +| Use Case | Best Choice | Why | +|---|---|---| +| **Casual LoRa chat** | Meshtastic | Mature, large community, good enough for non-sensitive use | +| **Off-grid data transfer** | Reticulum | Transport-agnostic, Python ecosystem, LXMF for messaging | +| **High-threat protest/shutdown** | Briar | Tor integration, one-hop privacy, proven in the field | +| **Experimental P2P mobile** | Berty | IPFS ecosystem, mobile-first design | +| **Security-critical mesh groups** | **QuicProChat** | MLS + PQ-KEM, multi-hop routing, self-hostable | + +**QuicProChat is for teams that need:** + +- End-to-end encrypted group messaging over mesh +- Post-compromise security (automatic key healing) +- Post-quantum protection (harvest-now-decrypt-later defense) +- Multi-transport flexibility (QUIC + LoRa + Serial) +- Auditable, standards-based cryptography (MLS RFC 9420) + +--- + +## Technical Differentiation Summary + +| Capability | Meshtastic | Reticulum | Briar | Berty | QuicProChat | +|---|---|---|---|---|---| +| **Multi-hop mesh** | ✓ | ✓ | ✗ | ✗ | ✓ | +| **LoRa native** | ✓ | ✓ | ✗ | ✗ | ✓ | +| **E2E groups** | ✗ | ✗ | ⚠️ | ⚠️ | ✓ | +| **Forward secrecy (groups)** | ✗ | ✗ | ⚠️ | ? | ✓ | +| **Post-compromise security** | ✗ | ✗ | ✗ | ? | ✓ | +| **Post-quantum** | ✗ | ✗ | ✗ | ✗ | ✓ | +| **IETF-standard crypto** | ✗ | ✗ | ✗ | ✗ | ✓ | +| **Rust/no_std capable** | ✗ | ✗ | ✗ | ✗ | ✓ | +| **Self-hostable server** | N/A | N/A | N/A | ✗ | ✓ | + +Legend: ✓ = yes, ✗ = no, ⚠️ = partial, ? = unclear/unaudited + +--- + +## What QuicProChat Gives Up + +Honest trade-offs: + +- **Maturity:** Meshtastic and Reticulum have years of production use. QuicProChat is early-stage. +- **Community size:** Meshtastic has hundreds of thousands of nodes. QuicProChat is a research project. +- **Simplicity:** Shared-key AES is simpler than MLS. QuicProChat trades simplicity for security. +- **Battery/bandwidth:** MLS adds overhead. On extremely constrained links (SF12/BW125 LoRa), this matters. +- **Real-world testing:** Briar has been used in actual protests and shutdowns. QuicProChat hasn't. + +--- + +## Roadmap to "Best Mesh Protocol" + +Current status (2026-03-30): + +- [x] S1: Binary wire format (CBOR) — complete +- [x] S2: Transport abstraction trait — complete +- [x] S3: Announce & discovery protocol — complete +- [ ] S4: Multi-hop routing — in progress +- [ ] S5: Truncated addresses + lightweight handshake — planned +- [x] S6: LoRa transport (mock) — complete, hardware integration next + +After S4-S5: + +- [ ] Hardware LoRa demo (SX1262, RNode) +- [ ] Termux integration (Android as LoRa node) +- [ ] Benchmark suite (crypto overhead on constrained devices) +- [ ] Security audit (MLS integration, mesh routing, hybrid KEM) + +--- + +## Further Reading + +- [Reticulum-Inspired Mesh Upgrade Plan](../../plans/reticulum-mesh-upgrade.md) — detailed sprint plan +- [Mesh Networking Guide](../../getting-started/mesh-networking.md) — user-facing mesh docs +- [Protocol Layers Overview](../protocol-layers/overview.md) — how the crypto stack composes +- [Why This Design, Not Signal/Matrix/...](why-not-signal.md) — comparison with traditional messengers +- [Comparison with Classical Protocols](protocol-comparison.md) — IRC, XMPP, Telegram comparison