quicproquo/docs/src/security/audit-scope.md

Security Audit Scope

Project Summary

quicprochat is a production-grade end-to-end encrypted group messenger implemented in Rust. It uses MLS (RFC 9420) for group key agreement with a hybrid post-quantum KEM (X25519 + ML-KEM-768), OPAQUE for password-authenticated key exchange, and QUIC + TLS 1.3 as the transport layer. The project comprises approximately 38,000 lines of Rust across 9 workspace crates, with 300+ tests passing.

Scope

Primary Scope (Critical)

These components handle all cryptographic operations and should receive the deepest scrutiny.

quicprochat-core -- All Cryptographic Primitives

File	Lines	Responsibility
src/hybrid_kem.rs	~630	Hybrid X25519 + ML-KEM-768 KEM: key generation, encrypt/decrypt, encapsulate/decapsulate, HKDF key derivation
src/hybrid_crypto.rs	~540	OpenMLS OpenMlsCrypto + OpenMlsProvider implementation with hybrid HPKE routing
src/identity.rs	~250	Ed25519 identity keypair: generation, signing, verification, zeroization
src/group.rs	~1080	MLS group state machine: create, join, add/remove members, send/receive, epoch management
src/keypackage.rs	~100	MLS KeyPackage generation with hybrid init keys
src/keystore.rs	~710	Disk-backed OpenMLS key store with file permission restrictions
src/sealed_sender.rs	~160	Sender identity + Ed25519 signature envelope inside MLS payload
src/pq_noise.rs	~690	Post-quantum Noise_XX handshake with ML-KEM-768 mixing
src/opaque_auth.rs	~20	OPAQUE cipher suite definition (Ristretto255, Triple-DH, Argon2id)
src/recovery.rs	~340	Recovery code generation, Argon2id key derivation, encrypted backup bundles
src/padding.rs	~270	Message padding to fixed buckets + uniform boundary padding
src/safety_numbers.rs	~80	Signal-style safety number computation
src/transcript.rs	~400	Encrypted hash-chained transcript archive

quicprochat-server/src/domain/auth.rs -- OPAQUE Server Logic

File	Lines	Responsibility
src/domain/auth.rs	~170	OPAQUE registration (start/finish), session token validation, expiry cleanup

Secondary Scope (Important)

These components handle transport security and trust anchors. They are lower risk than the primary scope but still security-relevant.

quicprochat-rpc -- RPC Transport Security

File	Lines	Responsibility
src/framing.rs	~200	Wire format encoding/decoding, payload size limits (4 MiB max)
src/auth_handshake.rs	~80	Session token exchange over QUIC bi-stream
src/server.rs	~300	QUIC server setup, TLS configuration, connection handling
src/middleware.rs	~200	Tower middleware: rate limiting, timeouts

quicprochat-kt -- Key Transparency

File	Lines	Responsibility
src/lib.rs	~65	Merkle log hash functions (leaf_hash, node_hash) with RFC 6962 domain separation
src/tree.rs	~150	Append-only Merkle tree (insert, root computation)
src/proof.rs	~100	Inclusion proof generation and verification
src/revocation.rs	~100	Key revocation log with reason codes

quicprochat-server -- Security-Relevant Server Components

File	Lines	Responsibility
src/domain/rate_limit.rs	~150	Per-client rate limiting
src/domain/traffic_resistance.rs	~100	Decoy traffic generation, timing jitter, payload padding
src/domain/moderation.rs	~100	Abuse prevention (report handling)
src/tls.rs	~100	TLS certificate loading and configuration

Out of Scope

The following components are explicitly excluded from the audit:

• Client SDKs: quicprochat-sdk, Go/Python/TypeScript/WASM/FFI bindings (thin wrappers)
• CLI/TUI client: quicprochat-client (user interface, no crypto logic)
• Plugin API: quicprochat-plugin-api (#![no_std] C-ABI interface, no crypto)
• P2P networking: quicprochat-p2p (iroh integration, feature-gated)
• Proto definitions: quicprochat-proto (generated code, no security logic)
• Documentation: mdBook sources, README, ROADMAP
• CI/CD: GitHub Actions, Dockerfiles, justfile
• Non-crypto server domain: user management, group metadata, blob storage, delivery routing

Specific Questions for Auditors

Hybrid KEM Construction

1. Is the hybrid combiner HKDF-SHA256(salt, X25519_ss || ML-KEM_ss, info) a sound dual-PRF construction? Does it provide IND-CCA2 security assuming either component is secure?
2. Is the nonce handling correct? The hybrid KEM uses random 12-byte nonces (not derived from HKDF). Is there a nonce collision risk at the expected message volume?
3. Is the derive_from_ikm() construction (HKDF -> seeded StdRng -> key generation) suitable for deterministic key derivation in the MLS HPKE key schedule?

OpenMLS Integration

4. Does the HybridCryptoProvider correctly satisfy the OpenMlsProvider trait contract? Are there edge cases where hybrid key detection by length could fail or be spoofed?
5. Is the DiskKeyStore implementation (wrapping MemoryStorage with disk flush) safe for concurrent access? Could a crash between MemoryStorage update and disk flush cause key loss?
6. Is the MLS group lifecycle (create, add_member with merge_pending_commit, join_group via StagedWelcome) correctly implemented? Are there state consistency issues after failed operations?

Timing Side-Channels

7. Are there timing side-channels in the OPAQUE registration/login flow? The opaque-ke crate uses Ristretto255 (constant-time), but is the surrounding code (deserialization, error handling) timing-safe?
8. Is constant_time_eq() in recovery.rs correctly implemented? The early return on length mismatch is intentional (lengths are not secret), but verify the XOR-accumulate loop.

Noise_XX + ML-KEM Layering

9. Is the PQ Noise handshake (pq_noise.rs) sound? Specifically:
   • Is ML-KEM ciphertext placement in message 2 correct (after ee DH, before se DH)?
   • Is mix_key(mlkem_ss) the right integration point for the post-quantum shared secret?
   • Does ML-KEM implicit rejection (pseudorandom wrong shared secret) cause any subtle failures beyond AEAD decryption error?

Zeroization

10. Is zeroization complete? Specifically:
    • x25519_dalek::StaticSecret does not publicly implement Zeroize. Is the HybridKeypair struct's x25519_sk field securely erased on drop?
    • Are there intermediate buffers or stack copies of secret material that escape Zeroizing wrappers?
    • Does the DiskKeyStore flush-on-write pattern leave secret material in OS page cache or filesystem buffers?

Key Transparency

11. Is the Merkle log construction (RFC 6962-style domain separation with 0x00/0x01 prefixes) resistant to second-preimage attacks?
12. Could an adversarial server forge inclusion proofs for non-existent entries?

Access

• Repository: git clone https://github.com/quicprochat/quicprochat
• Build: cargo build --workspace (Rust 1.75+, no system dependencies -- protobuf-src vendors protoc)
• Test: cargo test --workspace (300+ tests, runs in ~60s)
• Lint: cargo clippy --workspace -- -D warnings
• Documentation: cd docs && mdbook build

Key Entry Points

• Crypto primitives: crates/quicprochat-core/src/
• Server auth: crates/quicprochat-server/src/domain/auth.rs
• RPC framing: crates/quicprochat-rpc/src/framing.rs
• Key transparency: crates/quicprochat-kt/src/

Timeline and Budget

Based on the scope (approximately 5,000 lines of security-critical Rust code in primary scope, plus ~1,000 lines in secondary scope), we recommend:

• Duration: 4-6 weeks (2 auditors)
• Budget range: $80,000 - $150,000
• Firm type: Specialized cryptography audit firm (e.g., NCC Group Cryptography Services, Trail of Bits, Cure53, Quarkslab)

Suggested Audit Phases

1. Week 1-2: Hybrid KEM construction review, HKDF key derivation, zeroization audit
2. Week 2-3: OpenMLS integration, MLS group lifecycle, KeyPackage handling
3. Week 3-4: OPAQUE integration, PQ Noise handshake, timing analysis
4. Week 4-5: Key Transparency Merkle log, transport security (RPC framing)
5. Week 5-6: Report writing, finding triage, remediation discussion