Koch Laboratory

Ygoow: vorregistrierte Messung der eigenen Sicherheitsaussagen

Setzt den Eintrag vom 2026-07-10 fort, nun mit Produktnamen. Von Juli bis September 2026 wurden die Sicherheitsaussagen von Ygoow in zweistufige Karten überführt — erst Kriterien und Vorhersagen, dann die Messung — auf dem Zieltelefon oder in der Simulation: 37 Karten (24 mit vor dem Lauf festgehaltener Registrierung), 199 Vorhersagen im Register, davon 36 verfehlt, acht veröffentlichte Aussagen widerlegt und zurückgezogen, dazu Korrekturen überholter Aussagen des Juli-Eintrags. Konstruktionen zurückgehalten; Verkehrsergebnisse stammen aus einem Modell, nicht aus mitgeschnittenem Tor-Verkehr.

Koch Laboratory — Ygoow: vorregistrierte Messung der eigenen Sicherheitsaussagen

Der Eintrag vom 10. Juli 2026 („Metadaten-resistente, kontenlose Kommunikation”) beschrieb sieben Forschungsrichtungen zu einem Messenger mit taubem Relay, ohne das Produkt zu nennen. Das Produkt ist Ygoow (ygoow.com); die Android-App ist noch nicht veröffentlicht. Vom 24. Juli bis zum 29. September 2026 haben wir seine Sicherheitsaussagen in Messkarten überführt. Im Folgenden: Methode, Zählungen, bereits auf der Produktseite veröffentlichte Ergebnisse und Korrekturen zum Juli-Eintrag. Zusammenfassung der Methode (englisch): Measured, not assumed.

Methodik: die Karte in zwei Stufen. Stufe 1, festgehalten vor dem Start des Messinstruments: die Frage; der Gegner — der stärkste, den wir aus der öffentlichen Protokollbeschreibung bauen können; ein Populationsmodell mit berechnetem Zufallsniveau; Kriterien, numerische Vorhersagen, Kandidaten für eine Korrektur und eine Entscheidungsregel. Stufe 2, die Messung: eine Nullkontrolle (zwei Stichproben derselben Klasse) und eine Positivkontrolle (ein bekannter Effekt, der in derselben Sitzung erkannt werden muss); Zeit und Kosten auf dem Referenztelefon (ARM64, Release-Build), Verkehr, Speicher und Gruppen in einer Simulation des Produktionscodes oder seines Modells; ein Urteil zu jedem Kriterium und jeder Vorhersage, Ergänzungen nach den ersten Zahlen als post hoc gekennzeichnet, Abweichungen benannt. Die Praxis wurde unterwegs strenger: Seit dem 3. September stammt jede Zahl aus mindestens drei Durchläufen oder Zufalls-Seeds, seit dem 6. September gelangt Stufe 1 mit einem eigenen Commit vor der Messung ins Repository.

Zählungen (Stand 29. September 2026). Eine Karte ist ein Protokoll im Repository des Produkts.

Regeln, die Fehlschläge erzwungen haben.

1. Richtung 1 — Post-Compromise Security ohne zustandsbehafteten Server: die Primitive darunter

Frage. Verraten Verschlüsselung, Signatur, Schlüsselvereinbarung und Schlüsselableitung über ihre Laufzeit auf dem Telefon ein Geheimnis? Stand der Technik. TVLA und dudect (Welch-Test), RFC 8032, NIST SP 800-38D, RFC 9106, zxcvbn. Kriterium. |t| ≤ 4,5 in jedem Durchlauf bei sauberer Nullkontrolle und angeschlagener Positivkontrolle; Ausgabe übereinstimmend mit den Testvektoren. Methode. 11 Karten (2 vom 20. bis 29. September), Telefon und Simulation; die Heilung nach einer Kompromittierung selbst hat keine gemessen. Ergebnis. Widerlegt und behoben: Ed25519 (|t| = 60 und 71, nativ 2,6 und 1,6), die Quorum-Arithmetik (Richtung 7) und AES-GCM (Effekt rund 1,4 %, nur mit lokaler Uhr sichtbar; vor der Behebung veröffentlicht, nativ 24 von 24 Ablesungen auf Rauschniveau). X25519 sauber. Widerlegte Aussage: „ehrliche Stärkeanzeige” — die Stärke von Passwörtern nach dem Muster „Wort + Ziffern + Symbol” überschätzte sie im Median um 45 Bit; die Prüfung der Sicherungsdatei passierten 97 % davon, heute 0,3–0,6 %. Die Änderung vom 28. August, ohne Karte eingeführt (weniger Speicher bei der Schlüsselableitung der Sicherung), wurde zwei Tage später von einer Karte widerlegt. Weiter. Der Double Ratchet in der App, der auch die Lücke bei der Forward Secrecy schließt; eine ungeklärte Zeitanomalie in der SHA3-Bibliothek eines Drittanbieters. Konstruktion: zurückgehalten. Status: Primitive gemessen und in der App; Post-Compromise Security gebaut und mit Testvektoren verifiziert, außerhalb der App.

2. Richtung 2 — Post-Quanten-Hybrid (X25519 + ML-KEM)

Frage. Schützt der Hybrid die erste Nachricht gegen jemanden, der heute mitschneidet und X25519 später bricht, und passt er in den Schlüsselaustausch zwischen Kontakten? Stand der Technik. FIPS 203, Signal PQXDH, X25519MLKEM768, KyberSlash. Kriterium. Die Post-Quanten-Hälfte hält nach einem Bruch von X25519; eine Einladung passt in einen QR-Code mit Fehlerkorrekturstufe M; |t| ≤ 4,5 auf dem Telefon. Methode. 4 Karten: Analyse der Produktionsabläufe, die QR-Bibliothek der App, Zeitmessung auf dem Telefon. Ergebnis. Widerlegte Aussage, im Juli veröffentlicht: Der aus dem X25519-Geheimnis abgeleitete Post-Quanten-Schlüssel sollte die erste Nachricht schützen, doch zwei unterstützte Abläufe legen öffentliche Schlüssel offen, aus denen sich dieses Geheimnis nach einem Bruch von X25519 berechnen lässt; seit dem 23. August hängt der Post-Quanten-Schlüssel nicht mehr von X25519 ab. Widerlegt: Ein einzelner QR-Code ist zu dicht — nötig sind ein geteilter QR-Code, NFC oder ein Link. Widerlegt und behoben: eine geheimnisabhängige Division in der eigenen ML-KEM-Implementierung — auf dem Telefon 15,6 % (|t| = 339), nach der Behebung |t| = 3,9. Weiter. Einbindung in laufende Gespräche und in den Kontaktcode; bis dahin ist „jetzt mitschneiden, später entschlüsseln” in der App nicht abgedeckt. Status: gebaut und an die veröffentlichten akkumulierten Testvektoren gebunden, außerhalb der App.

3. Richtung 3 — Metadaten-Resistenz-Schicht

Frage. Was liest der Relay aus Größe, Rhythmus und Anzahl der Frames, ohne Inhalt und IP-Adresse zu sehen? Stand der Technik. Loopix, Netflow-Padding in Tor, Likelihood-Quotienten-Test, Transinformation. Kriterium. Die Größe trägt ≤ 0,5 Bit über die Nachrichtenlänge und hängt nur von öffentlichen Parametern ab; kein Frame ist nach seiner Größe „sicher echt”; die Gruppierung der Adressen eines Geräts liegt bei ≤ 2× Zufallsniveau. Methode. 11 Karten (4 vom 20. bis 29. September): Modell des öffentlichen Protokolls auf den Pfaden des Produktionscodes, als Gegner ein Relay mit Uhr. Ergebnis. Widerlegte und behobene Aussagen: „nie die exakte Länge” (Räume ohne Auffüllung; heute 0,043 Bit über die Länge) und „ununterscheidbare Dummy-Frames” (immer die kleinste Klasse; heute 0,0002 Bit in der Größe, 0,0018 Bit in den Abständen). Widerlegte Aussage: „der Relay weiß nicht, wann du sendest” — Cover-Traffic verbirgt Nachrichten, nicht Sitzungen, und ist standardmäßig aus; ohne ihn behält der Relay 98,5 % der Information darüber, wann jemand kommuniziert. Widerlegte Aussagen: „der Relay bündelt Adressen nicht zu einem Gerät” und „Personas verraten kein gemeinsames Gerät” — ein Likelihood-Quotienten-Gegner gruppiert die Adressen eines Geräts zu 85–90 % nach einer 15-Minuten-Epoche, zu 99,8 % innerhalb von 30 Minuten. Gefunden: Der unverschlüsselte Nachrichtenzähler im Header verbindet ein Gespräch über die Adressrotation hinweg zu 81–89 % bei 20 aktiven Gesprächen. Weiter. Zwei gemessene Entwürfe zur Schließung des Zeitkanals warten auf eine Entscheidung; Header-Verschlüsselung in Arbeit; Messung an echtem Verkehr. Konstruktion: zurückgehalten. Status: Größen-Padding und optionaler Cover-Traffic in der App; Zeitkanal und Zähler offen.

4. Richtung 4 — Adressloses Rendezvous mit Epochen-Rotation

Frage. Unterbricht die Rotation der Gesprächsadresse etwa alle 15 Minuten die für den Relay sichtbare Kontinuität, ohne Nachrichten zu verlieren? Stand der Technik. Tor-Onion-Services, Store-and-Forward-Zustellung, Verkettbarkeit beim Wechsel eines Bezeichners. Kriterium. Verlust von Nachrichten an einen abwesenden Empfänger ≤ 0,1 %; Verknüpfung aufeinanderfolgender Epochen eines Gesprächs allein über den Cursor ≤ 1 %. Methode. 3 Karten (2 vom 20. bis 29. September): Simulation mit und ohne Zustellung im Hintergrund. Ergebnis. Widerlegt und behoben: In der Standardkonfiguration konnten Nachrichten an jemanden, der länger als 15–30 Minuten abwesend war, ohne Meldung verloren gehen (57–58 % im Modell; heute 0 %), und der Nachhol-Cursor verknüpfte selbst die Adressen eines Gesprächs (100 %; heute 0 %). Weiter. Die Ergebnisse von zwei Karten vom 22. September — in einem späteren Eintrag. Konstruktion: zurückgehalten. Status: Adressrotation und spurloses Nachholen in der App; gegenüber dem Relay genügt die Rotation allein nicht (Richtung 3).

5. Richtung 5 — Koordinatorlose Heilung von Gruppen-Epochen

Frage. Erreicht eine Änderung der Gruppenzusammensetzung alle Mitglieder, auch abwesende, und was erfährt der Relay aus den Steuer-Frames über die Gruppe? Stand der Technik. MLS (RFC 9420) mit ordnendem Server, Sender Keys. Kriterium. Mindestens 99 % der Mitglieder innerhalb von 24 h auf demselben Schlüssel bei Zustellung im Hintergrund (95 % ohne); Verlust von Raumnachrichten ≤ 0,5 % in jedem Seed. Methode. 5 Karten (3 vom 20. bis 29. September): Simulation auf einem Modell und auf dem Produktionscode. Ergebnis. Widerlegt: Eine Änderung erreichte nur Mitglieder, die den Raum öffneten, solange sie frisch war — im Modell hatten innerhalb eines Tages 3–9 % der Mitglieder denselben Schlüssel, und 29–55 % der Raumnachrichten gingen verloren. Das Kriterium erfüllte erst eine nach den ersten Zahlen ergänzte Variante (post hoc): 100 % und unter 0,5 %. Sie wurde dennoch übernommen, die Abweichung von der eigenen Regel ist auf der Karte vermerkt; der Test auf Geräten steht aus. Gefunden und behoben: Beim Öffnen eines Raums las der Relay dessen Größe und Zusammensetzung; er sieht weiterhin, dass sich die Zusammensetzung ändert (100 % im Modell), und am Zähler im Header, wie viele Mitglieder schreiben. Weiter. Schutz vor wiederholten Schlüssel-Frames; Forward Secrecy für die Verteilung der Sender Keys; ein entferntes Mitglied sieht weiterhin, wann der Raum aktiv ist. Konstruktion: zurückgehalten. Status: koordinatorlose Heilung und Zustellung im Hintergrund in der App; die Grenzen unter „Weiter” bleiben offen.

6. Richtung 6 — Abstreitbarer Speicher mit verstecktem Volumen

Frage. Bleibt das versteckte Profil nach Monaten der Nutzung unbeweisbar — gegenüber jemandem, der den Speicher des Telefons kopiert und die Entsperrzeit misst? Stand der Technik. Versteckte Volumes der VeraCrypt-Klasse; der Gegner mit mehreren Momentaufnahmen (Czeskis u. a., 2008). Kriterium. Ohne Decoy-Passwort arbeitet ein Detektor auf einer oder zwei Kopien nur auf Zufallsniveau; kein Datenverlust in mindestens 300 skriptgesteuerten Lebenszyklen; kein Unterschied in der Entsperrzeit. Methode. 3 Karten: Produktionscode des Speichers über Monate simulierter Nutzung, Stoppuhr auf dem Telefon. Ergebnis. Widerlegte Aussage: „auf dem Datenträger ununterscheidbar” — nach 30 Tagen verriet eine Kopie das versteckte Profil bei 69 % der simulierten Telefone mit nie geöffnetem Decoy, zwei Kopien bei 98–100 %; das Entsperren dauerte rund 1,1 s länger, und die Nutzung des Decoys konnte das versteckte Profil überschreiben. Nach dem Umbau: 0 verlorene Daten in 600 Lebenszyklen, 0 Größenabweichungen in 7200 Momentaufnahmen, Entsperrzeit −3 bis +28 ms gegenüber einem Telefon ohne Decoy. Die für den Umbau registrierte Vorhersage traf nicht ein — ein Passwortwechsel hatte eine eigene Signatur; die letzte von zwei weiteren Korrekturen wurde per Test geprüft, nicht an der Population. Weiter. Mit dem Decoy-Passwort in fremder Hand zeigen zwei Kopien weiterhin die Nutzung des versteckten Profils; eine Re-Randomisierung ohne Schlüssel kostet heute das 14- bis 40-Fache des Schreibbudgets. Konstruktion: zurückgehalten. Status: in der App, über den Lebenszyklus gemessen; die Grenzen bei herausgegebenem Decoy-Passwort sind benannt.

7. Richtung 7 — Bedingter Zugriff mit Quorum

Frage. Bleiben bei der Prüfung der Entsperrbedingungen — Passwort, Datei, Link, K-von-N-Quorum, Hardwareschlüssel — Geheimnis und Standort verborgen? Stand der Technik. Shamir-Schlüsselteilung über GF(2⁸); clientseitig durchgesetzte Bedingungen. Kriterium. Quorum-Arithmetik mit |t| ≤ 4,5 auf dem Telefon; die Prüfung einer Bedingung sendet nichts außerhalb von Tor. Methode. Ohne eigene Karte: Die Quorum-Arithmetik hat eine Karte der Richtung 1 gemessen, die Standortbedingung wurde außerhalb der Karten geprüft. Ergebnis. Widerlegt und behoben: Die tabellenbasierte Multiplikation in GF(2⁸) leckte (|t| bis 1222); die Version ohne Verzweigungen und Tabellen ist über alle 65 536 Eingabepaare erschöpfend äquivalent. Negatives Ergebnis: Die Standortbedingung wurde entfernt, weil ihre Prüfung die umliegenden WLAN- und Mobilfunknetze außerhalb von Tor an Google sendete. Weiter. Messung des Bedingungsgraphen selbst. Konstruktion: zurückgehalten. Status: Sperre mit beliebiger Kombination von Bedingungen in der App; der Bedingungsgraph ohne Messkarte.

Korrekturen zum Eintrag vom 2026-07-10

Status der Richtung. Gebaut, aber außerhalb der App: Post-Compromise Security und der Post-Quanten-Hybrid. Offen gegenüber dem Relay: Zeitkanal und Zähler im Header. Außerhalb dieser Serie: eine unabhängige Prüfung von Protokoll und Implementierung sowie eine Messung an echtem Verkehr. Die elf Karten vom 20. bis 29. September beschreibt ein späterer Eintrag; den laufenden Stand führt die Seite ygoow.com/progress.

Zeitnachweis

Dieser Text wurde bei der Veröffentlichung gehasht und gestempelt. Zur Prüfung sind beide Dateien nötig: der Stempel belegt, dass genau eine Bytefolge zu diesem Zeitpunkt existierte, und nur die Quelle unten ist diese Bytefolge. Jede spätere Änderung verschiebt den Hash und bricht die Übereinstimmung — genau das ist der Zweck.

· @529.57 · 2026-W40

SHA-256 des gestempelten Textes: e7809aa121bebb53a42cf9597437a55ba01b50a48bcf2a28cf4c049345f99442

Prüfen mit: ots verify <Nachweis> --file <Quelle>