Libreria crypto/protocollo Voron — richiesta di revisione

Questo è il nucleo crittografico e di protocollo di messaggistica di un piccolo progetto di messenger E2EE, estratto da solo per una revisione esterna. Non è il prodotto completo — il client Android e la configurazione di deployment sono stati volutamente esclusi; questa è solo la parte che ha bisogno di essere esaminata.

Cosa contiene

• common/ — la libreria stessa:
  • e2ee/ — X3DH-lite (accordo sulle chiavi asincrono) + un Double Ratchet sopra, costruito su Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (primitive fornite dal JDK, nulla di scritto a mano a quel livello).
  • crypto/ — sottili wrapper attorno a quelle primitive JDK.
  • group/ — messaggistica di gruppo tramite uno schema sender-keys (l'approccio pre-MLS usato dai primi gruppi WhatsApp/Signal), più un registro eventi a catena di hash firmato lato client per appartenenza/ruoli, dato che il relay non ha alcun concetto di gruppi.
  • onion/ — un trasporto opzionale a crittografia a strati (numero di hop fisso, padding a bucket di dimensioni) per impedire al relay di collegare direttamente l'IP di una connessione alla sua chiave di identità.
  • client/, transport/, backup/ — il protocollo wire, l'handshake di trasporto Noise_IK e un formato di backup crittografato.
• server/ — un'implementazione di relay di riferimento: routing store-and-forward, directory di prekey, mailbox offline, il ruolo di hop onion. Fiducia deliberatamente minima: il relay non vede mai il testo in chiaro, non conserva un messaggio più a lungo del tempo di consegna e (per progettazione) non ha alcuna consapevolezza dell'appartenenza ai gruppi.
• client/ — un semplice harness di test console JVM (non una vera app) usato per far interagire common/server tra loro nei test di integrazione, più alcuni PoC di exploit autonomi (vedi sotto).
• security-audit/ — report delle precedenti tornate di revisione interna, i bug trovati e quelli già corretti. Leggi questo prima di segnalare qualcosa — c'è una reale possibilità che sia già qui dentro. REPORT.md è quello principale; ADVERSARIAL_REVIEW_PAVEL.md è una passata successiva e più mirata; fuzz/ e client/.../exploit/ contengono PoC eseguibili, non solo descrizioni.

Modello di minaccia, in breve

• Il relay non è una parte fidata. Instrada testo cifrato e dati di directory (prekey pubblicate) e si presume sia attivamente malintenzionato, non solo curioso — molti dei bug corretti in security-audit/ sono esattamente "cosa può fare un relay ostile".
• Le sessioni 1:1 mirano alla segretezza in avanti (X3DH) e alla sicurezza post-compromissione (il DH-ratchet sopra). Le sessioni di gruppo si basano su sender-keys: un cambio di appartenenza rinnova le chiavi dell'intero gruppo, ma una singola chiave del mittente compromessa espone i messaggi di quell'epoca — non c'è alcun ratchet per-messaggio a livello di gruppo (non è MLS/TreeKEM completo, un taglio di ambito deliberato, documentato in group/GroupCryptoSession.kt).
• L'onion routing nasconde il collegamento IP↔identità a un relay che vede un solo hop e riempie i frame in bucket di dimensioni fisse, così la correlazione passiva delle dimensioni tra gli hop non deanonimizzi banalmente un circuito. Non nasconde la correlazione temporale a un avversario che osserva entrambe le estremità contemporaneamente — servirebbe traffico di copertura / mixing, che non è implementato. Questo è evidenziato esplicitamente in security-audit/REPORT.md e ADVERSARIAL_REVIEW_PAVEL.md, non è qualcosa che viene nascosto.

Cosa vogliamo specificamente che venga controllato

• L'integrazione X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — questa è l'unica costruzione crittografica davvero su misura qui; tutto ciò che sta sotto è di serie. È stata rivista internamente più volte (vedi security-audit/) ma mai da nessuno al di fuori di questo progetto.
• Il modello di autorizzazione del registro di controllo di gruppo (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — una catena di hash firmata lato client senza alcuna applicazione lato server.
• Qualsiasi cosa nel livello onion-routing che non sia già coperta dall'avvertenza documentata sulla correlazione temporale di cui sopra.

Esecuzione

./gradlew test

Progetto Gradle/Kotlin standard, JDK 17+. Nessun accesso alla rete o servizi in esecuzione necessari per la suite di unit test. security-audit/README.md contiene le istruzioni per il fuzzing live del relay e i PoC di correlazione onion, che richiedono processi locali in esecuzione (non puntare mai nulla di tutto ciò a un host di produzione).

Cosa non è

Nessun audit crittografico indipendente è stato condotto su questo. Tutto ciò che c'è in security-audit/ è revisione ingegneristica interna — accurata, ma è auto-revisione, senza supporto di prove formali e senza un track record professionale/istituzionale alle spalle. Trattalo come un punto di partenza per la revisione, non come una certificazione.