Metadaten-resistente, kontenlose Kommunikation
Sieben Forschungsrichtungen in angewandter Kryptographie für einen Messenger mit taubem Relay — inklusive eines veröffentlichten negativen Ergebnisses.
Koch Laboratory — Forschung zu Privatsphäre und angewandter Kryptographie
Koch Laboratory erforscht metadaten-resistente, kontenlose Kommunikation — Systeme, deren vermittelnder Server „taub” ist: er kennt weder Identitäten noch Schlüssel noch den Sozialgraphen der Nutzer. Nachfolgend die aktuellen Forschungsrichtungen. Jede löst ein konkretes, ungelöstes technisches Problem, für das es keine fertige Standardlösung gibt.
Methodik. Jede Richtung als Prozess: Problemstellung → Hypothese → Referenzimplementierung in zwei unabhängigen Sprachen (Python/Dart) mit gemeinsamen Testvektoren → Verifikation als testbare Eigenschaft. Datierte Projektdokumentation und Testdisziplin halten das Ergebnis über Iterationen hinweg.
Publikationshinweis (IP). Für patentfähige Richtungen veröffentlichen wir Problem, Stand der Technik und Erfolgskriterium — nicht die Lösungskonstruktion. Grund: Das EPC kennt keine Neuheitsschonfrist; eine öffentliche Offenbarung vor einer etwaigen Anmeldung zerstört die Neuheit unwiderruflich. Wo „Konstruktion: zurückgehalten” steht, wird das technische Detail als Anmeldematerial vorgehalten.
1. Post-Compromise Security ohne zustandsbehafteten Server
Forschungsfrage. Lässt sich „Selbstheilung” einer Sitzung nach Endgeräte-Kompromittierung (PCS, Double-Ratchet-Klasse) ohne einen Prekey-Server erreichen — also bei Erhalt eines tauben, zustandslosen Relays? Warum schwierig. Der Industriestandard (Signal X3DH/PQXDH) setzt einen semi-vertrauenswürdigen Schlüsselserver voraus; unsere Architektur verbietet ihn. Zudem muss die Authentifizierung rotierender DH-Schlüssel ohne digitale Signaturen auskommen, um die kryptographische Abstreitbarkeit nicht zu brechen. Erfolgskriterium. Wiederherstellung der Vertraulichkeit nach Kompromittierung bei erhaltenem zustandslosem Relay und erhaltener Abstreitbarkeit, verifiziert als testbare Eigenschaft. Erreicht (2026-07-14). Von Entwurf zu implementiert und als testbare Eigenschaft verifiziert: eine Referenz in zwei unabhängigen Sprachen, durch gemeinsame Vektoren gebunden, plus Tests bestätigen die Vertraulichkeitswiederherstellung nach Kompromittierung bei erhaltenem zustandslosem, tauben Relay und erhaltener Abstreitbarkeit (Authentifizierung ohne Signaturen). Offen benannte Grenze: eine bewusst markierte Anfangsphase mit schwächerer Garantie bleibt bestehen. Der Lösungsweg (Konstruktion) — nicht veröffentlicht. Konstruktion: zurückgehalten (offene Patentoption). Status: implementiert und verifiziert (Referenz + Vektoren + Tests); Einbindung in den Live-Transport laufend.
2. Post-Quanten-Hybrid (X25519 + ML-KEM)
Forschungsfrage. Wie ergänzt man Post-Quanten-Sicherheit („harvest now, decrypt later”) im inhaltschützenden Schlüsselaustausch auf Mobilgeräten, ohne die heutige Kryptographie zu schwächen und ohne die Verkehrs-Ununterscheidbarkeit zu verletzen? Warum schwierig. ML-KEM-Schlüssel/Ciphertexte sind groß (~1,1 kB) — Handshake und QR-Code wachsen, der Handshake kann die feste Zelle der Metadatenschicht überschreiten. Parameterwahl, FFI-Integration (Rust/liboqs) und Zwei-Implementierungs-Parität sind offen. Ansatz. Hybridkonstruktion durch standardmäßige Kombination zweier unabhängiger Geheimnisse (klassisches X25519 + ML-KEM) in einem KDF — sicher, solange ein Primitiv hält; additiv, zuerst für inhaltschützende Wurzeln. (Das Hybridschema selbst ist Stand der Technik und wird veröffentlicht; spezifische Parameterwahlen für die Metadatenschicht werden gesondert behandelt.) Status: Entwurf/Design.
3. Metadaten-Resistenz-Schicht (Mixnet / Cover-Traffic / feste Zelle)
Forschungsfrage. Lässt sich Verkehrs-Ununterscheidbarkeit (wer-mit-wem, wann, wie viel) gegenüber einem globalen passiven Beobachter halten — nicht nur idealisiert, sondern real auf Android/Tor, wo der Leak in den Implementierungsdetails lebt? Warum schwierig. Mixnet-Beweise (Loopix/Nym) setzen einen idealen Poisson-Prozess und bit-identische Zellen voraus. Der reale Leak lebt in der Lücke zur Implementierung: Android Doze, TCP-Retransmission, Benachrichtigungen. Cover-Traffic muss unabhängig vom Realverkehr sein — adaptiver Cover verrät genau die zu verbergende Größe. Negatives Ergebnis (veröffentlicht). Der ursprüngliche „lastabhängige Cover”-Entwurf wurde als fehlerhaft nachgewiesen: adaptiver Cover ist trivial unterscheidbar, das Einschalten des Schutzes hebt den Nutzer selbst hervor. Umgestellt auf konstante Poisson-Rate (Stand der Technik: Loopix/Nym). Ein bewusst publiziertes Beispiel für Hypothesen-Falsifikation. Was wir veröffentlichen (bereits im Produkt-Whitepaper offengelegt). Nachrichten werden auf feste Größen-Buckets aufgefüllt (Relay sieht nur wenige Größen, nie die exakte Länge); ein optionaler Modus sendet mit konstanter Kadenz und füllt Lücken mit ununterscheidbaren Dummy-Frames; jede Persona auf einem eigenen Tor-Circuit. Offen benannte Grenze: ein globaler passiver Beobachter beider Enden kann weiterhin Timing-Korrelation versuchen — die Kadenz hebt die Schwelle, eliminiert sie nicht. Methodik (veröffentlicht). Ununterscheidbarkeit als testbare Eigenschaft: Byte-Assertions, pcap-Diff, Timing-Verteilungstest, Plattform-Fuzz. Konstruktion der festen Zelle und Fragmentierung (Zellenformat, Fragmentierungsschema, ein Code-Pfad real/Dummy): zurückgehalten (offene Patentoption). Status: teilweise implementiert; Kern im Design.
4. Adressloses Rendezvous mit Epochen-Rotation
Forschungsfrage. Wie stellt man Nachrichten ohne Konten und Adressen zu, sodass der Relay den Sitzungs-Selektor nie im Voraus kennt und Aktivität nicht über die Zeit verketten kann? Warum schwierig. Der Selektor muss eine nur den beiden Parteien bekannte Capability sein; die periodische Rotation erzeugt Randprobleme bei Empfangsfenstern und Auffindbarkeit. Entstanden als Antwort auf eine im externen Review gefundene Linkability-Lücke. Was wir veröffentlichen (bereits im Produkt-Whitepaper offengelegt). Die Gesprächsadresse ist kein fester Handle — sie wird in kurzem Takt neu abgeleitet (eine neue, nicht erratbare ID etwa alle 15 Min), und die Rotation jedes Gesprächs ist durch dessen eigenen gemeinsamen Schlüssel phasenverschoben, sodass der Relay Adressen nicht zu „einem Gerät” bündeln kann; der Server hält keinen Per-Empfänger-Zustand (Cursor client-seitig). Folge: eine einzelne Timing-Korrelation bestätigt höchstens ein 15-Min-Fenster, nicht die Gesprächshistorie. Erfolgskriterium. Zustellung ohne Konto/Adresse bei einem Relay, der den Selektor nicht im Voraus kennt und Aktivität nicht über Epochen verkettet. Konstruktion (Selektor-Ableitung als Capability aus ECDH, Epochen-Tag-Mechanik, Empfangsfenster/Auffindbarkeit): zurückgehalten (offene Patentoption — als sensibel markierte Richtung). Status: implementiert und getestet.
5. Deterministische Fork-Heilung von Gruppen-Epochen (koordinatorlos)
Forschungsfrage. Wie löst man nebenläufige Zusammensetzungsänderungen — die einen „Fork” der Schlüsselhistorie erzeugen — deterministisch und ohne zentralen Koordinator? Warum schwierig. Ein Problem der Klasse „verteilter Konsens”. Der Standard (MLS, RFC 9420) verlangt einen ordnungserzwingenden Server; unser Relay ist taub, also muss der Konflikt client-seitig aufgelöst werden. Erfolgskriterium. Deterministische, konvergente Fork-Auflösung bei allen Clients ohne Koordinator und ohne Verlust der MLS-Sicherheitseigenschaften. Konstruktion: zurückgehalten (offene Patentoption). Status: implementiert und getestet.
6. Abstreitbarer Speicher mit verstecktem Volumen (Zwangsresistenz)
Achse orthogonal zum bedingten Zugriff (Richtung 7): hier geht es um glaubhaftes Bestreiten der Existenz von Daten und den Zwangsmodus, nicht um die Entsperrbedingungen selbst. Forschungsfrage. Wie erreicht man glaubhafte Abstreitbarkeit (VeraCrypt-Klasse) in einem mobilen, kontenlosen Speicher — mit automatischem Decoy-Profil und Zwangsresistenz (Duress)? Warum schwierig. Die Existenz des versteckten Volumens muss unbeweisbar sein (gleiche Größe, stets Chaff); der Lock-Header darf den Typ der genutzten Bedingung nicht verraten (forensischer Leak), und Ändern/Deaktivieren des Decoys darf die Abstreitbarkeit nicht brechen. Erfolgskriterium. Unbeweisbarkeit der Existenz des versteckten Volumens, Verbergen des Bedingungstyps im Header und Erhalt der Abstreitbarkeit unter Zwang. Konstruktion (Decoy-/Real-Slot-Blob, typ-verbergender Trial, Duress-Pfad): zurückgehalten (offene Patentoption). Status: Mechanismus implementiert; Glaubwürdigkeit des Duress-Modus unverifiziert (offene Projektfrage).
7. Bedingter Zugriff mit Quorum: Bedingungs-Umschlag (Zugriffsgraph)
Forschungsfrage. Lässt sich ein Zugriffsmechanismus bauen, bei dem der Schlüssel ein beliebiges Artefakt oder eine Kombination davon ist (Passwort, Datei, NFC-Präsenz, K-von-N-Quorum von Personen, Zeitverzögerung), verbunden zu einem Bedingungsgraphen (AND / OR / Schwelle), bei erhaltener Oracle-Freiheit (falscher und fehlender Schlüssel ununterscheidbar) und taubem Relay? Warum schwierig. Der Standard bindet Inhalt an einen Schlüssel oder einen Schlüsselserver. Heterogene Geheimnisquellen zu einem Schlüssel zu verbinden — ohne zu offenbaren, welche Bedingungen genutzt wurden (Metadaten!), ohne Treffer-Oracle und ohne Server — ist offen. Quorum als Geheimnisquelle (Shamir-Schlüsselteilung) muss sich mit einer Schwellenbedingung zusammensetzen lassen, sodass K−1 Anteile nichts verraten. Was wir veröffentlichen (bereits im Produkt-Whitepaper offengelegt). Das Quorum-Primitiv (Shamir K-von-N über GF(2⁸)) und die „No-Oracle”-Eigenschaft sind produktseitig öffentlich beschrieben — wir wiederholen sie als Wissensstand, nicht als neue Offenbarung. Erfolgskriterium. Ein Container, der beliebige Geheimnisquellen zu einem Zugriffsgraphen vereint, ohne Oracle, ohne Server; Quorum mit Schwelle kombinierbar; kein Leak der genutzten Bedingungen in den Klartext-Header. Erreicht (2026-07-14). Als testbare Eigenschaft abgeschlossen: ein Container vereint heterogene Geheimnisquellen zu einem Zugriffsgraphen mit verschachtelten Schwellen (AND / OR / Schwelle t-von-n, beliebige Tiefe), ohne Oracle an irgendeinem Knoten (falscher/fehlender Schlüssel ununterscheidbar) und ohne Server; Quorum als Schwellenknoten komponierbar. Durch Tests verifiziert (u. a. zwei unabhängige Zugriffspfade, Recovery über OR, verschachtelte Schwellen, Oracle-Freiheit). Konstruktion (Format, Kombinationsmechanik) — nicht veröffentlicht. Konstruktion (Containerformat, Träger-Gating der Anteile, AND/OR/Schwellen-Graph): zurückgehalten (offene Patentoption — direkt §2.1: „RDKV-Bedingungs-Umschlag”, „Quorum als Geheimnisquelle”). Status: implementiert und getestet (Mechanismus v1 + Graph v2 mit verschachtelten Schwellen); Konstruktion zurückgehalten; UX-Einbindung laufend.