Voron crypto/protocol library — Bitte um Überprüfung

Dies ist der Kern der Krypto- und Nachrichtenprotokolle eines kleinen E2EE-Messenger-Projekts, der für eine externe Überprüfung separat herausgelöst wurde. Es ist nicht das gesamte Produkt — der Android-Client und die Bereitstellungskonfiguration wurden absichtlich weggelassen; dies ist nur der Teil, der einer Begutachtung bedarf.

Was ist enthalten

• common/ — die Bibliothek selbst:
  • e2ee/ — X3DH-lite (asynchroner Schlüsselaustausch) + ein Double Ratchet darüber, basierend auf Curve25519/ChaCha20-Poly1305/Ed25519/HKDF (von JDK bereitgestellte Primitive, nichts selbst entwickelt auf dieser Ebene).
  • crypto/ — dünne Wrapper um diese JDK-Primitive.
  • group/ — Gruppenbenachrichtigungen über ein Sender-Keys-Schema (der Pre-MLS-Ansatz, den frühe WhatsApp/Signal-Gruppen verwendeten), plus ein clientseitiges signiertes Hash-Chain-Ereignisprotokoll für Mitgliedschaft/Rollen, da der Relay überhaupt kein Konzept von Gruppen hat.
  • onion/ — ein optionaler Transport mit geschichteter Verschlüsselung (feste Hop-Anzahl, Größen-Bucket-Padding), um zu verhindern, dass der Relay die IP einer Verbindung direkt mit ihrem Identitätsschlüssel verknüpft.
  • client/, transport/, backup/ — das Drahtprotokoll, der Noise_IK-Transport-Handshake und ein verschlüsseltes Backup-Format.
• server/ — eine Referenzimplementierung des Relays: Store-and-Forward-Routing, Prekey-Verzeichnis, Offline-Postfach, die Onion-Hop-Rolle. Absichtlich minimales Vertrauen: der Relay sieht niemals Klartext, hält eine Nachricht nie länger als für die Zustellung nötig und hat (konstruktionsbedingt) keinerlei Kenntnis von Gruppenmitgliedschaften.
• client/ — eine einfache JVM-Konsolen-Testumgebung (keine echte App), die verwendet wird, um common/server in Integrationstests gegeneinander zu treiben, plus einige eigenständige Exploit-PoCs (siehe unten).
• security-audit/ — Berichte von früheren internen Überprüfungsdurchgängen, die gefundenen Fehler und die bereits behobenen. Lesen Sie dies, bevor Sie etwas melden — es besteht eine reale Chance, dass es bereits hier enthalten ist. REPORT.md ist der Hauptbericht; ADVERSARIAL_REVIEW_PAVEL.md ist ein späterer, engerer Durchgang; fuzz/ und client/.../exploit/ enthalten ausführbare PoCs, nicht nur Beschreibungen.

Bedrohungsmodell, Kurzfassung

• Der Relay ist keine vertrauenswürdige Partei. Er leitet Chiffretext und Verzeichnisdaten (veröffentlichte Prekeys) weiter und wird als aktiv böswillig angenommen, nicht nur neugierig — mehrere der in security-audit/ behobenen Fehler sind genau 'was kann ein feindseliger Relay tun'.
• 1:1-Sitzungen zielen auf Forward Secrecy (X3DH) und Post-Compromise Security (die DH-Ratchet darüber). Gruppensitzungen verwenden Sender-Keys: eine Änderung der Mitgliedschaft verschlüsselt die gesamte Gruppe neu, aber ein einzelner kompromittierter Sender-Key legt die Nachrichten dieser Epoche offen — es gibt keine Pro-Nachricht-Ratchet auf der Gruppenebene (nicht vollständiges MLS/TreeKEM, eine bewusste Umfangseinschränkung, dokumentiert in group/GroupCryptoSession.kt).
• Onion-Routing verbirgt die IP↔Identitäts-Verbindung vor einem Relay, das nur einen Hop sieht, und füllt Frames auf feste Größen-Buckets auf, sodass passive Größenkorrelation über Hops hinweg eine Schaltung nicht trivial deanonymisieren kann. Es verbirgt nicht die Timing-Korrelation vor einem Angreifer, der beide Enden gleichzeitig beobachtet — das würde Tarnverkehr / Mixing erfordern, was nicht implementiert ist. Dies wird explizit in security-audit/REPORT.md und ADVERSARIAL_REVIEW_PAVEL.md erwähnt, nicht etwas, das versteckt wird.

Was wir speziell überprüft haben möchten

• Die Integration von X3DH-lite ↔ Double Ratchet (common/src/main/kotlin/messenger/common/e2ee/) — dies ist die einzige wirklich maßgeschneiderte kryptografische Konstruktion hier, alles darunter ist Standard. Sie wurde mehrfach intern überprüft (siehe security-audit/), aber nie von jemandem außerhalb dieses Projekts.
• Das Autorisierungsmodell des Gruppenkontrollprotokolls (common/src/main/kotlin/messenger/common/group/GroupControlLog.kt) — eine clientseitige signierte Hash-Chain ohne jegliche Serverdurchsetzung.
• Alles in der Onion-Routing-Schicht, was nicht bereits durch den oben dokumentierten Timing-Korrelationsvorbehalt abgedeckt ist.

Ausführung

./gradlew test

Standard-Gradle/Kotlin-Projekt, JDK 17+. Kein Netzwerkzugriff oder laufende Dienste für die Unit-Test-Suite erforderlich. security-audit/README.md enthält Anweisungen für die Live-Relay-Fuzzing- und Onion-Korrelations-PoCs, die lokale Prozesse erfordern (richten Sie nichts davon auf einen Produktionshost).

Was dies nicht ist

Es wurde kein unabhängiges kryptografisches Audit durchgeführt. Alles in security-audit/ ist eine interne technische Überprüfung — sorgfältig, aber Selbstüberprüfung, ohne formale Beweisführung und ohne professionelle/institutionelle Erfolgsbilanz dahinter. Betrachten Sie es als Ausgangspunkt für eine Überprüfung, nicht als Zertifizierung.