c/quicproquo
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore: rename project quicnprotochat -> quicproquo (binaries: qpq)

Browse Source 
Rename the entire workspace:
- Crate packages: quicnprotochat-{core,proto,server,client,gui,p2p,mobile} -> quicproquo-*
- Binary names: quicnprotochat -> qpq, quicnprotochat-server -> qpq-server,
  quicnprotochat-gui -> qpq-gui
- Default files: *-state.bin -> qpq-state.bin, *-server.toml -> qpq-server.toml,
  *.db -> qpq.db
- Environment variable prefix: QUICNPROTOCHAT_* -> QPQ_*
- App identifier: chat.quicnproto.gui -> chat.quicproquo.gui
- Proto package: quicnprotochat.bench -> quicproquo.bench
- All documentation, Docker, CI, and script references updated

HKDF domain-separation strings and P2P ALPN remain unchanged for
backward compatibility with existing encrypted state and wire protocol.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Chris Nennemann
2026-03-01 20:11:51 +01:00
parent 553de3a2b7
commit 853ca4fec0
152 changed files with 4070 additions and 788 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
docs/src/design-rationale/protocol-comparison.md
View File

@@ -1,6 +1,6 @@
# Comparison with Classical Chat Protocols
This page compares quicnprotochat against **classical and legacy chat protocols** -- IRC+SSL, XMPP (with and without OMEMO), Telegram's MTProto, and plain TCP/TLS chat systems -- to demonstrate what a modern, cryptographically rigorous design provides over protocols that were designed before end-to-end encryption, post-compromise security, and post-quantum readiness were practical concerns.
This page compares quicproquo against **classical and legacy chat protocols** -- IRC+SSL, XMPP (with and without OMEMO), Telegram's MTProto, and plain TCP/TLS chat systems -- to demonstrate what a modern, cryptographically rigorous design provides over protocols that were designed before end-to-end encryption, post-compromise security, and post-quantum readiness were practical concerns.
For a comparison against modern E2E-encrypted protocols (Signal, Matrix/Olm/Megolm), see [Why This Design, Not Signal/Matrix/...](why-not-signal.md).
@@ -9,7 +9,7 @@ For a comparison against modern E2E-encrypted protocols (Signal, Matrix/Olm/Mego
## At a glance
```
Classical IRC+SSL quicnprotochat
Classical IRC+SSL quicproquo
───────────────── ──────────────
You ──TLS──▶ Server ──TLS──▶ Bob You ──QUIC/TLS──▶ Server ──QUIC/TLS──▶ Bob
@@ -19,13 +19,13 @@ For a comparison against modern E2E-encrypted protocols (Signal, Matrix/Olm/Mego
messages (cannot decrypt)
```
The fundamental difference: **classical protocols trust the server with your plaintext**. quicnprotochat's server is cryptographically excluded from reading message content.
The fundamental difference: **classical protocols trust the server with your plaintext**. quicproquo's server is cryptographically excluded from reading message content.
---
## Protocol comparison matrix
| Property | IRC+SSL | XMPP+TLS | XMPP+OMEMO | Telegram (MTProto) | quicnprotochat |
| Property | IRC+SSL | XMPP+TLS | XMPP+OMEMO | Telegram (MTProto) | quicproquo |
|---|---|---|---|---|---|
| **Transport encryption** | TLS (server-to-server optional) | STARTTLS / direct TLS | STARTTLS / direct TLS | MTProto 2.0 (custom) | QUIC + TLS 1.3 |
| **End-to-end encryption** | None | None | Double Ratchet (1:1) | "Secret chats" only (1:1) | MLS RFC 9420 (groups native) |
@@ -41,7 +41,7 @@ The fundamental difference: **classical protocols trust the server with your pla
---
## Deep dive: IRC+SSL vs. quicnprotochat
## Deep dive: IRC+SSL vs. quicproquo
IRC (Internet Relay Chat) is the archetypal chat protocol, designed in 1988. Adding SSL/TLS wraps the TCP connection in transport encryption, but the protocol's security model remains fundamentally unchanged.
@@ -66,7 +66,7 @@ IRC (Internet Relay Chat) is the archetypal chat protocol, designed in 1988. Add
4. **No post-compromise security.** There is no mechanism to recover from a key compromise. If a server is breached, all messages flowing through it are exposed indefinitely.
5. **No identity binding.** NickServ password authentication is plaintext over the IRC protocol (inside TLS, but visible to the server). There is no cryptographic binding between a user's identity and their messages.
### What happens when Alice sends a message on quicnprotochat
### What happens when Alice sends a message on quicproquo
```
┌───────┐ ┌────────┐ ┌─────┐
@@ -93,7 +93,7 @@ IRC (Internet Relay Chat) is the archetypal chat protocol, designed in 1988. Add
---
## Deep dive: XMPP+OMEMO vs. quicnprotochat
## Deep dive: XMPP+OMEMO vs. quicproquo
XMPP with OMEMO (XEP-0384) adds end-to-end encryption via the Signal Double Ratchet protocol. This is a significant improvement over plain XMPP, but OMEMO inherits the limitations of the Signal Protocol for group messaging.
@@ -109,7 +109,7 @@ XMPP with OMEMO (XEP-0384) adds end-to-end encryption via the Signal Double Ratc
3 encryptions per message
O(n) cost per send
quicnprotochat MLS group (4 members)
quicproquo MLS group (4 members)
Alice encrypts once with group epoch key:
┌───────┐ ── MLS_encrypt(epoch_key) ──▶ Server
@@ -120,7 +120,7 @@ XMPP with OMEMO (XEP-0384) adds end-to-end encryption via the Signal Double Ratc
(all decrypt with same epoch key)
```
| Property | XMPP+OMEMO groups | quicnprotochat MLS groups |
| Property | XMPP+OMEMO groups | quicproquo MLS groups |
|---|---|---|
| **Encryption per message** | O(n) -- encrypt once per recipient | O(1) -- single MLS application message |
| **Add member** | O(n) -- distribute sender keys to all | O(log n) -- single MLS Commit |
@@ -131,7 +131,7 @@ XMPP with OMEMO (XEP-0384) adds end-to-end encryption via the Signal Double Ratc
---
## Deep dive: Telegram (MTProto) vs. quicnprotochat
## Deep dive: Telegram (MTProto) vs. quicproquo
Telegram is often perceived as a "secure" messenger, but its default mode provides **no end-to-end encryption**. Only "Secret Chats" (1:1 only, not available on desktop) use E2E encryption.
@@ -163,7 +163,7 @@ Telegram is often perceived as a "secure" messenger, but its default mode provid
### Comparison
| Property | Telegram Cloud Chats | Telegram Secret Chats | quicnprotochat |
| Property | Telegram Cloud Chats | Telegram Secret Chats | quicproquo |
|---|---|---|---|
| **Server reads plaintext** | Yes | No | No |
| **Group E2E** | No | N/A (1:1 only) | Yes (MLS) |
@@ -173,7 +173,7 @@ Telegram is often perceived as a "secure" messenger, but its default mode provid
| **Open source server** | No | No | Yes (MIT license) |
| **Post-quantum** | None | None | Hybrid KEM (X25519 + ML-KEM-768) |
**Critical concern with Telegram:** MTProto is a custom, proprietary cryptographic protocol that has not undergone the same level of independent cryptographic review as standard protocols (TLS, MLS, Signal Protocol). Multiple academic papers have identified weaknesses in earlier versions. quicnprotochat exclusively uses IETF-standardized protocols (TLS 1.3, MLS RFC 9420) and widely reviewed cryptographic primitives.
**Critical concern with Telegram:** MTProto is a custom, proprietary cryptographic protocol that has not undergone the same level of independent cryptographic review as standard protocols (TLS, MLS, Signal Protocol). Multiple academic papers have identified weaknesses in earlier versions. quicproquo exclusively uses IETF-standardized protocols (TLS 1.3, MLS RFC 9420) and widely reviewed cryptographic primitives.
---
@@ -208,7 +208,7 @@ An attacker gains root access to the chat server.
│ sees metadata (who talks to whom, │
│ when, message sizes). │
│ │
│ quicnprotochat: │
│ quicproquo: │
│ Cannot read messages (MLS E2E). │
│ Sees metadata (recipient keys, │
│ timing, sizes). │
@@ -243,7 +243,7 @@ A state-level adversary records all encrypted traffic today, planning to decrypt
Telegram (MTProto / custom DH):
└── Quantum computer breaks DH → all recorded messages decrypted
quicnprotochat (Hybrid KEM):
quicproquo (Hybrid KEM):
└── Transport: QUIC/TLS with ECDHE → quantum computer breaks this layer
└── Inner layer: MLS content encrypted with group epoch keys
└── Hybrid KEM envelope: X25519 + ML-KEM-768
@@ -252,7 +252,7 @@ A state-level adversary records all encrypted traffic today, planning to decrypt
└── Combined key: STILL SECURE (both must be broken)
```
quicnprotochat's hybrid "belt and suspenders" design means that **even if X25519 falls to a quantum computer, ML-KEM-768 protects the content**. The adversary's recorded ciphertext remains useless.
quicproquo's hybrid "belt and suspenders" design means that **even if X25519 falls to a quantum computer, ML-KEM-768 protects the content**. The adversary's recorded ciphertext remains useless.
### Scenario 3: Device theft / compromise
@@ -279,7 +279,7 @@ An attacker steals Alice's unlocked device and extracts her key material.
Messages after T: all accessible (cloud sync)
Recovery: terminate session from another device
quicnprotochat:
quicproquo:
Messages before T: protected (MLS forward secrecy, past epoch keys deleted)
Messages after T: exposed only until next MLS epoch advance
Recovery: ANY group member issues an MLS Update proposal →
@@ -293,7 +293,7 @@ An attacker steals Alice's unlocked device and extracts her key material.
### Why QUIC over TCP
Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) blocking. quicnprotochat uses QUIC, which provides independent streams over UDP.
Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) blocking. quicproquo uses QUIC, which provides independent streams over UDP.
```
TCP (IRC/XMPP): all streams share one ordered byte stream
@@ -308,7 +308,7 @@ Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) b
└── ALL streams blocked until retransmit
QUIC (quicnprotochat): each stream is independent
QUIC (quicproquo): each stream is independent
──────────────────────────────────────────────────
Stream A: ████████░░██████████████ (only A waits)
@@ -334,7 +334,7 @@ Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) b
════════════════════════════════════════════════════
Total: 2-3 round trips before first message
quicnprotochat: QUIC integrates crypto into handshake = 1 RTT (or 0-RTT)
quicproquo: QUIC integrates crypto into handshake = 1 RTT (or 0-RTT)
──────────────────────────────────────────────────────────────────────────
Client ──Initial(ClientHello)──▶ Server │
Client ◀──Initial(ServerHello)── Server │ 1 RTT total
@@ -363,7 +363,7 @@ Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) b
Phone number + SMS OTP ← carrier and Telegram see phone number
(identity = phone number) ← no cryptographic identity
quicnprotochat (OPAQUE PAKE):
quicproquo (OPAQUE PAKE):
Client ──blinded_element──▶ Server │ Server never sees password
Client ◀──evaluated_element── Server │ Mutual authentication
Client ──finalization──▶ Server │ Session key derived
@@ -406,7 +406,7 @@ Classical protocols (IRC, XMPP) use TCP, which suffers from head-of-line (HOL) b
│ Schema via XSD exists but rarely enforced at runtime. │
└──────────────────────────────────────────────────────────┘
Cap'n Proto (quicnprotochat):
Cap'n Proto (quicproquo):
┌──────────────────────────────────────────────────────────┐
│ [8-byte aligned struct with pointers] │
│ │
@@ -434,7 +434,7 @@ The following diagram maps each protocol against the security properties it prov
Telegram Cloud · · · · · · · ·
Telegram Secret △ · ● · · ● · ·
Signal ● · ● ● △ ● · ·
quicnprotochat ● ● ● ● ● ● ● ●
quicproquo ● ● ● ● ● ● ● ●
Legend: ● = yes △ = partial · = no
FS = forward secrecy PCS = post-compromise security
@@ -446,12 +446,12 @@ The following diagram maps each protocol against the security properties it prov
---
## The quicnprotochat advantage: a layered defense
## The quicproquo advantage: a layered defense
Classical protocols rely on a **single layer** of security (transport TLS). quicnprotochat applies defense in depth with **three independent layers**, each of which must be broken separately:
Classical protocols rely on a **single layer** of security (transport TLS). quicproquo applies defense in depth with **three independent layers**, each of which must be broken separately:
```
IRC+SSL security layers: quicnprotochat security layers:
IRC+SSL security layers: quicproquo security layers:
┌─────────────────────────┐ ┌─────────────────────────────────┐
│ TLS (transport) │ │ Layer 3: Hybrid KEM envelope │
@@ -474,7 +474,7 @@ Classical protocols rely on a **single layer** of security (transport TLS). quic
To read a message, attacker must break:
IRC+SSL: TLS (1 layer)
quicnprotochat: TLS + MLS + Hybrid KEM (3 layers)
quicproquo: TLS + MLS + Hybrid KEM (3 layers)
```
---
@@ -483,7 +483,7 @@ Classical protocols rely on a **single layer** of security (transport TLS). quic
Fairness demands acknowledging where classical protocols genuinely excel:
| Advantage | IRC | quicnprotochat |
| Advantage | IRC | quicproquo |
|---|---|---|
| **Simplicity** | Telnet-compatible text protocol | Binary protocol requiring client implementation |
| **Maturity** | 35+ years of production use | Early-stage research project |
@@ -493,7 +493,7 @@ Fairness demands acknowledging where classical protocols genuinely excel:
| **Public channels** | Designed for open, unencrypted discussion | Designed for private, encrypted communication |
| **Anonymity** | No identity required | Requires Ed25519 identity keypair |
IRC remains an excellent choice for **public, open discussion** where encryption is not needed and simplicity is valued. quicnprotochat is designed for a different threat model: private communication where **confidentiality, forward secrecy, and post-compromise security** are requirements, not luxuries.
IRC remains an excellent choice for **public, open discussion** where encryption is not needed and simplicity is valued. quicproquo is designed for a different threat model: private communication where **confidentiality, forward secrecy, and post-compromise security** are requirements, not luxuries.
---
@@ -501,10 +501,10 @@ IRC remains an excellent choice for **public, open discussion** where encryption
For users and operators coming from classical chat systems, here is what changes practically:
| Concern | Classical (IRC/XMPP) | quicnprotochat |
| Concern | Classical (IRC/XMPP) | quicproquo |
|---|---|---|
| **Server setup** | Install IRCd, configure TLS cert | `cargo build && ./quicnprotochat-server` (auto-generates TLS cert) |
| **Client setup** | Install any IRC client | `./quicnprotochat-client register-user` (generates Ed25519 identity) |
| **Server setup** | Install IRCd, configure TLS cert | `cargo build && ./qpq-server` (auto-generates TLS cert) |
| **Client setup** | Install any IRC client | `./quicproquo-client register-user` (generates Ed25519 identity) |
| **Joining a group** | `/join #channel` | Receive MLS Welcome message from group creator |
| **Sending a message** | Type and press enter | Same -- client handles MLS encryption transparently |
| **Server admin sees messages** | Yes (always) | No (never -- server sees only ciphertext) |
@@ -518,7 +518,7 @@ For users and operators coming from classical chat systems, here is what changes
- [Why This Design, Not Signal/Matrix/...](why-not-signal.md) -- comparison with modern E2E-encrypted protocols
- [Protocol Layers Overview](../protocol-layers/overview.md) -- detailed protocol stack documentation
- [Threat Model](../cryptography/threat-model.md) -- what quicnprotochat does and does not protect against
- [Threat Model](../cryptography/threat-model.md) -- what quicproquo does and does not protect against
- [Post-Quantum Readiness](../cryptography/post-quantum-readiness.md) -- hybrid KEM design and rationale
- [MLS (RFC 9420)](../protocol-layers/mls.md) -- deep dive into the group key agreement protocol
- [Architecture Overview](../architecture/overview.md) -- system-level architecture