Voron crypto/protocol library — request for review

This is the crypto and messaging-protocol core of a small E2EE messenger project, pulled out on its own for outside review. It is not the whole product — the Android client and deployment config are intentionally left out; this is just the part that needs eyes on it.

What's in here

• common/ — the library itself:
  • e2ee/ — X3DH-lite (asynchronous key agreement) + a Double Ratchet on top, built on Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (JDK-provided primitives, nothing hand-rolled at that layer).
  • crypto/ — thin wrappers over those JDK primitives.
  • group/ — group messaging via a sender-keys scheme (the pre-MLS approach early WhatsApp/Signal groups used), plus a client-side signed hash-chain event log for membership/roles since the relay has no concept of groups at all.
  • onion/ — an optional layered-encryption transport (fixed hop count, size-bucket padding) to keep the relay from directly linking a connection's IP to its identity key.
  • client/, transport/, backup/ — the wire protocol, Noise_IK transport handshake, and an encrypted-backup format.
• server/ — a reference relay implementation: store-and-forward routing, prekey directory, offline mailbox, the onion-hop role. Deliberately minimal trust: the relay never sees plaintext, never holds a message longer than delivery takes, and (by design) has zero group-membership awareness.
• client/ — a plain JVM console test harness (not a real app) used to drive common/server against each other in integration tests, plus a few standalone exploit PoCs (see below).
• security-audit/ — write-ups from prior internal review passes, the bugs they found, and the ones already fixed. Read this before reporting something — there's a real chance it's already in here. REPORT.md is the main one; ADVERSARIAL_REVIEW_PAVEL.md is a later, narrower pass; fuzz/ and client/.../exploit/ have runnable PoCs, not just descriptions.

Threat model, short version

• The relay is not a trusted party. It routes ciphertext and directory data (published prekeys) and is assumed to be actively malicious, not just curious — several of the fixed bugs in security-audit/ are exactly "what can a hostile relay do."
• 1:1 sessions aim for forward secrecy (X3DH) and post-compromise security (the DH-ratchet on top). Group sessions are sender-keys: a membership change rekeys the whole group, but a single compromised sender key exposes that epoch's messages — there is no per-message ratchet at the group layer (not full MLS/TreeKEM, a deliberate scope cut, documented in group/GroupCryptoSession.kt).
• Onion routing hides the IP↔identity link from a relay that only sees one hop, and pads frames to fixed size buckets so passive size-correlation across hops doesn't trivially deanonymize a circuit. It does not hide timing correlation from an adversary watching both ends at once — that would need cover traffic / mixing, which isn't implemented. This is called out explicitly in security-audit/REPORT.md and ADVERSARIAL_REVIEW_PAVEL.md, not something being hidden.

What we specifically want checked

• The X3DH-lite ↔ Double Ratchet integration (common/src/main/kotlin/messenger/common/e2ee/) — this is the one genuinely bespoke cryptographic construction here, everything under it is off-the-shelf. It has been reviewed internally multiple times (see security-audit/) but never by anyone outside this project.
• The group control-log's authorization model (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — a client-side signed hash-chain with no server enforcement at all.
• Anything in the onion-routing layer that isn't already covered by the documented timing-correlation caveat above.

Running it

./gradlew test

Standard Gradle/Kotlin project, JDK 17+. No network access or running services needed for the unit-level suite. security-audit/README.md has instructions for the live relay-fuzzing and onion-correlation PoCs, which do need local processes running (never point any of it at a production host).

What this isn't

No independent cryptographic audit has been done on this. Everything in security-audit/ is internal engineering review — careful, but self-review, with no formal-proof backing and no professional/institutional track record behind it. Treat it as a starting point for review, not a certification.