Bibliothèque crypto/protocole Voron — demande de revue

Ceci est le cœur crypto et protocole de messagerie d'un petit projet de messagerie E2EE, extrait et isolé pour une revue externe. Ce n'est pas le produit complet — le client Android et la configuration de déploiement sont volontairement laissés de côté ; c'est uniquement la partie qui a besoin d'être examinée.

Ce que contient ce dépôt

• common/ — la bibliothèque elle-même :
  • e2ee/ — X3DH-lite (accord de clés asynchrone) + un Double Ratchet par-dessus, construit sur Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (primitives fournies par le JDK, rien de fait maison à cette couche).
  • crypto/ — de fins wrappers autour de ces primitives JDK.
  • group/ — messagerie de groupe via un schéma sender-keys (l'approche pré-MLS utilisée par les premiers groupes WhatsApp/Signal), plus un journal d'événements à chaîne de hachage signée côté client pour l'adhésion/les rôles, étant donné que le relais n'a aucune notion de groupe.
  • onion/ — un transport optionnel à chiffrement en couches (nombre de sauts fixe, bourrage par plages de tailles) pour empêcher le relais de lier directement l'IP d'une connexion à sa clé d'identité.
  • client/, transport/, backup/ — le protocole de transmission, la poignée de main de transport Noise_IK et un format de sauvegarde chiffrée.
• server/ — une implémentation de relais de référence : routage store-and-forward, annuaire de prekeys, boîte aux lettres hors ligne, le rôle de saut oignon. Confiance délibérément minimale : le relais ne voit jamais de texte clair, ne conserve jamais un message plus longtemps que le temps de livraison et (par conception) n'a aucune connaissance de l'appartenance à un groupe.
• client/ — un simple harnais de test en console JVM (pas une vraie application) utilisé pour confronter common/server dans les tests d'intégration, plus quelques PoCs d'exploitation autonomes (voir plus bas).
• security-audit/ — des comptes rendus des précédentes passes de revue interne, des bugs qu'elles ont trouvés et de ceux déjà corrigés. Lisez ceci avant de signaler quoi que ce soit — il y a de fortes chances que ce soit déjà dedans. REPORT.md est le principal ; ADVERSARIAL_REVIEW_PAVEL.md est une passe ultérieure, plus ciblée ; fuzz/ et client/.../exploit/ contiennent des PoCs exécutables, pas seulement des descriptions.

Modèle de menace, version courte

• Le relais n'est pas une partie de confiance. Il achemine le texte chiffré et les données d'annuaire (prekeys publiées) et est supposé activement malveillant, pas simplement curieux — plusieurs des bugs corrigés dans security-audit/ portent exactement sur « que peut faire un relais hostile ? »
• Les sessions 1:1 visent la forward secrecy (X3DH) et la sécurité post-compromission (le DH-ratchet par-dessus). Les sessions de groupe utilisent sender-keys : un changement d'adhésion renouvelle les clés de tout le groupe, mais une seule clé d'émetteur compromise expose les messages de cette époque — il n'y a pas de ratchet par message au niveau du groupe (pas un MLS/TreeKEM complet, une réduction de périmètre délibérée, documentée dans group/GroupCryptoSession.kt).
• Le routage oignon masque le lien IP↔identité à un relais qui ne voit qu'un seul saut, et bourre les trames dans des plages de tailles fixes afin que la corrélation passive de taille entre les sauts ne dé-anonymise pas trivialement un circuit. Il ne masque pas la corrélation temporelle face à un adversaire qui observe les deux extrémités à la fois — cela nécessiterait du trafic de couverture / du mélange, ce qui n'est pas implémenté. Cela est signalé explicitement dans security-audit/REPORT.md et ADVERSARIAL_REVIEW_PAVEL.md, et ce n'est pas quelque chose que l'on cache.

Ce que nous voulons spécifiquement faire examiner

• L'intégration X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — c'est la seule construction cryptographique véritablement sur mesure ici, tout ce qui se trouve en dessous est standard. Elle a été revue en interne à plusieurs reprises (voir security-audit/) mais jamais par quelqu'un d'extérieur à ce projet.
• Le modèle d'autorisation du journal de contrôle de groupe (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — une chaîne de hachage signée côté client, sans aucune application côté serveur.
• Tout ce qui, dans la couche de routage oignon, n'est pas déjà couvert par la réserve documentée ci-dessus concernant la corrélation temporelle.

Exécution

./gradlew test

Projet Gradle/Kotlin standard, JDK 17+. Aucun accès réseau ni service en cours d'exécution n'est nécessaire pour la suite de tests unitaires. security-audit/README.md contient les instructions pour les PoCs de fuzzing du relais en direct et de corrélation oignon, qui nécessitent des processus locaux en cours d'exécution (ne les pointez jamais vers un hôte de production).

Ce que ce n'est pas

Aucun audit cryptographique indépendant n'a été réalisé sur ce projet. Tout ce qui se trouve dans security-audit/ est une revue d'ingénierie interne — minutieuse, mais il s'agit d'une auto-revue, sans preuve formelle à l'appui et sans références professionnelles ou institutionnelles. Considérez-la comme un point de départ pour la revue, pas comme une certification.