# Koch Laboratory — Ygoow: prerejestrowany pomiar własnych twierdzeń o bezpieczeństwie · Forschungsportfolio / Portfolio badawcze / Research Portfolio

> **Zasada publikacji.** Metodę publikujemy w całości. Z wyników przytaczamy wyłącznie liczby już jawne na ygoow.com oraz liczniki zbiorcze; konstrukcje rozwiązań wymuszonych przez pomiary pozostają wstrzymane.
> **Zasada uczciwości.** To pomiar własnego kodu wykonany przez jego autorów, nie audyt. Chybione predykcje i obalone twierdzenia stoją obok trafionych; z 37 kart 24 mają etap rejestracji zapisany w repozytorium przed pomiarem, a liczby o ruchu sieciowym pochodzą z modelu protokołu, nie z przechwyconego ruchu Tor.

---
---

# 🇵🇱 WERSJA POLSKA

## Koch Laboratory — Ygoow: prerejestrowany pomiar własnych twierdzeń o bezpieczeństwie

Wpis z 10 lipca 2026 („Komunikacja odporna na metadane, bezkontowa") opisał siedem kierunków badań nad komunikatorem z głuchym pośrednikiem, bez nazwy produktu. Tym produktem jest Ygoow (ygoow.com); aplikacja na Androida nie jest jeszcze wydana. Od 24 lipca do 29 września 2026 jego twierdzenia o bezpieczeństwie zamienialiśmy w karty pomiarowe. Niżej: metoda, liczniki, wyniki już jawne na stronie produktu i korekty wpisu lipcowego. Streszczenie metody (po angielsku): [Measured, not assumed](https://ygoow.com/blog/2026-09-10-measured-not-assumed/).

**Metodyka: karta w dwóch etapach.** Etap 1, spisany przed uruchomieniem przyrządu: pytanie; przeciwnik — najsilniejszy, jakiego umiemy zbudować z publicznego opisu protokołu; model populacji z policzonym poziomem przypadku; kryteria, predykcje liczbowe, kandydaci na naprawę i reguła decyzyjna. Etap 2, pomiar: kontrola null (dwie próbki tej samej klasy) i kontrola pozytywna (znany efekt, który musi zostać wykryty w tej samej sesji); czas i koszt na telefonie referencyjnym (ARM64, build release), ruch, magazyn i grupy w symulacji kodu produkcyjnego lub jego modelu; werdykt dla każdego kryterium i każdej predykcji, dopiski po pierwszych liczbach oznaczone jako post hoc, odstępstwa nazwane. Praktyka zaostrzała się w trakcie: od 3 września każda liczba pochodzi z co najmniej trzech przebiegów lub ziaren losowych, od 6 września etap 1 trafia do repozytorium osobnym commitem przed pomiarem.

**Liczniki (stan na 29 września 2026).** Karta to jeden protokół w repozytorium produktu.

- 37 kart (24 lipca – 29 września), wszystkie z etapem 2; wyniki 11 z nich, z 20–29 września, nie są jeszcze opublikowane. Etap 1 w osobnym commicie przed pomiarem mają 24, wszystkie od 6 września; 13 wcześniejszych zapisało kryteria i wyniki w jednym commicie, więc kolejność poświadcza w nich tylko tekst karty.
- Rejestr predykcji (od 3 września, 25 kart): 199 predykcji — 113 trafionych, 48 częściowo lub tylko co do kierunku, 36 chybionych, 2 nieocenialne; chybienie ma 19 z tych kart.
- Obalone twierdzenia: 8 zdań, które ygoow.com opublikowało jako właściwość produktu, a karta im zaprzeczyła; wszystkie wycofano lub przepisano (niżej: „twierdzenie obalone"). Dwa kolejne stały tylko w dokumentacji wewnętrznej.
- Na kierunki: 1 — 11, 2 — 4, 3 — 11, 4 — 3, 5 — 5, 6 — 3, 7 — 0.

**Reguły wymuszone przez chybienia.**

- Czas mierzymy tylko na docelowym telefonie, w buildzie release, a negatyw przyjmujemy tylko przy kontroli pozytywnej, która zadziałała w tej samej sesji: ML-KEM był na desktopie czysty, a na telefonie dawał 15,6 % różnicy czasu; przebieg debug nie widział nawet znanego wycieku.
- Przeciwnik co najmniej tak silny, jak najsilniejszy możliwy z publicznego protokołu: słabszy wybiera złą naprawę. Trzy predykcje jego siły chybiły w jedną stronę, 6–24-krotnie.
- Przed rejestracją progu: poziom przypadku, osiągalność progu i jeden przypadek przeprowadzony ręcznie przez mechanizm, z ogona rozkładu.
- Liczby o ruchu pochodzą z modelu publicznego protokołu i zadeklarowanej populacji, nie z przechwyconego ruchu Tor.

### 1. Kierunek 1 — bezpieczeństwo po kompromitacji bez serwera stanowego: prymitywy pod spodem
**Pytanie.** Czy szyfr, podpis, uzgadnianie i wyprowadzanie klucza zdradzają sekret czasem wykonania na telefonie?
**Stan techniki.** TVLA i dudect (test Welcha), RFC 8032, NIST SP 800-38D, RFC 9106, zxcvbn.
**Kryterium.** |t| ≤ 4,5 w każdym przebiegu przy czystej kontroli null i zadziałanej kontroli pozytywnej; wynik zgodny z wektorami.
**Metoda.** 11 kart (2 z 20–29 września), telefon i symulacja; samego leczenia po kompromitacji żadna nie mierzyła.
**Wynik.** Obalone i naprawione: Ed25519 (|t| = 60 i 71, natywnie 2,6 i 1,6), arytmetyka kworum (kierunek 7) i AES-GCM (efekt ok. 1,4 %, widoczny tylko z lokalnego zegara; opublikowany przed naprawą, natywnie 24 z 24 odczytów na poziomie szumu). X25519 czysty. Twierdzenie obalone: „uczciwy miernik siły" — siłę haseł „słowo + cyfry + symbol" zawyżał o medianę 45 bitów; przez bramkę kopii zapasowej przechodziło ich 97 %, dziś 0,3–0,6 %. Zmianę z 28 sierpnia, wprowadzoną bez karty (mniej pamięci w wyprowadzaniu klucza kopii), karta obaliła dwa dni później.
**Dalej.** Double Ratchet w aplikacji, co zamknie też lukę poufności przyszłej; niewyjaśniona anomalia czasowa zewnętrznej biblioteki SHA3.
**Konstrukcja: wstrzymana.**
**Status:** prymitywy zmierzone i w aplikacji; leczenie po kompromitacji zbudowane i zweryfikowane wektorami, poza aplikacją.

### 2. Kierunek 2 — hybryda post-kwantowa (X25519 + ML-KEM)
**Pytanie.** Czy hybryda chroni pierwszą wiadomość przed kimś, kto nagrywa dziś i złamie X25519 później, i czy mieści się w wymianie kluczy między kontaktami?
**Stan techniki.** FIPS 203, Signal PQXDH, X25519MLKEM768, KyberSlash.
**Kryterium.** Połowa post-kwantowa trzyma po złamaniu X25519; zaproszenie mieści się w jednym kodzie QR przy korekcji błędów M; |t| ≤ 4,5 na telefonie.
**Metoda.** 4 karty: analiza przepływów produkcyjnych, biblioteka QR aplikacji, pomiar czasu na telefonie.
**Wynik.** Twierdzenie obalone, opublikowane w lipcu: klucz post-kwantowy wyprowadzany z sekretu X25519 miał chronić pierwszą wiadomość, lecz dwa obsługiwane przepływy wystawiają klucze publiczne, z których po złamaniu X25519 ten sekret da się odtworzyć; od 23 sierpnia klucz post-kwantowy nie zależy od X25519. Obalone: jeden kod QR jest za gęsty — potrzebny QR dzielony, NFC albo link. Obalone i naprawione: dzielenie zależne od sekretu we własnej implementacji ML-KEM — na telefonie 15,6 % (|t| = 339), po naprawie |t| = 3,9.
**Dalej.** Wpięcie w żywe rozmowy i w kod kontaktu; do tego czasu „nagraj teraz, odszyfruj później" nie jest w aplikacji pokryte.
**Status:** zbudowane i przypięte do opublikowanych wektorów zbiorczych, poza aplikacją.

### 3. Kierunek 3 — warstwa odporności na metadane
**Pytanie.** Co relay wyczyta z rozmiaru, rytmu i liczby ramek, nie widząc treści ani adresu IP?
**Stan techniki.** Loopix, wyściółka netflow Tora, test ilorazu wiarygodności, informacja wzajemna.
**Kryterium.** Rozmiar niesie ≤ 0,5 bita o długości wiadomości i zależy tylko od parametrów jawnych; żadna ramka nie jest po rozmiarze „na pewno prawdziwa"; grupowanie adresów urządzenia ≤ 2× poziomu przypadku.
**Metoda.** 11 kart (4 z 20–29 września): model publicznego protokołu na ścieżkach kodu produkcyjnego, przeciwnik — relay z zegarem.
**Wynik.** Twierdzenia obalone i naprawione: „nigdy dokładna długość" (pokoje bez dopełniania; dziś 0,043 bita długości) i „nieodróżnialne ramki pozorne" (zawsze najmniejsza klasa; dziś 0,0002 bita w rozmiarze, 0,0018 bita w odstępach). Twierdzenie obalone: „relay nie wie, kiedy wysyłasz" — ruch pozorny maskuje wiadomości, nie sesje, i jest domyślnie wyłączony; bez niego relay zachowuje 98,5 % informacji o tym, kiedy ktoś rozmawia. Twierdzenia obalone: „relay nie połączy adresów w jedno urządzenie" i „persony nie zdradzają wspólnego urządzenia" — przeciwnik ilorazu wiarygodności grupuje adresy urządzenia w 85–90 % po jednej 15-minutowej epoce, w 99,8 % w ciągu 30 minut. Znalezione: jawny licznik wiadomości w nagłówku łączy rozmowę przez rotację adresu w 81–89 % przy 20 aktywnych rozmowach.
**Dalej.** Dwa zmierzone projekty zamknięcia kanału czasu czekają na decyzję; szyfrowanie nagłówka w toku; pomiar na prawdziwym ruchu.
**Konstrukcja: wstrzymana.**
**Status:** dopełnianie rozmiaru i opcjonalny ruch pozorny w aplikacji; kanał czasu i licznik otwarte.

### 4. Kierunek 4 — bezadresowy rendezvous z rotacją epokową
**Pytanie.** Czy rotacja adresu rozmowy co około 15 minut zrywa ciągłość widoczną dla relaya, nie gubiąc wiadomości?
**Stan techniki.** Usługi cebulowe Tora, dostarczanie store-and-forward, powiązywalność przy zmianie identyfikatora.
**Kryterium.** Utrata wiadomości do nieobecnego odbiorcy ≤ 0,1 %; łączenie kolejnych epok rozmowy po samym kursorze ≤ 1 %.
**Metoda.** 3 karty (2 z 20–29 września): symulacja z dostarczaniem w tle i bez niego.
**Wynik.** Obalone i naprawione: w konfiguracji domyślnej wiadomości do kogoś nieobecnego dłużej niż 15–30 minut mogły ginąć bez komunikatu (57–58 % w modelu; dziś 0 %), a kursor nadrabiania sam łączył adresy rozmowy (100 %; dziś 0 %).
**Dalej.** Wyniki dwóch kart z 22 września — w kolejnym wpisie.
**Konstrukcja: wstrzymana.**
**Status:** rotacja adresów i nadrabianie bez śladu w aplikacji; wobec relaya sama rotacja nie wystarcza (kierunek 3).

### 5. Kierunek 5 — gojenie rozgałęzień epok w grupach bez koordynatora
**Pytanie.** Czy zmiana składu grupy dociera do wszystkich członków, także nieobecnych, i co relay wie o grupie z ramek sterujących?
**Stan techniki.** MLS (RFC 9420) z serwerem porządkującym, Sender Keys.
**Kryterium.** Co najmniej 99 % członków na wspólnym kluczu w ciągu 24 h przy dostarczaniu w tle (95 % bez niego); utrata wiadomości pokoju ≤ 0,5 % w każdym ziarnie.
**Metoda.** 5 kart (3 z 20–29 września): symulacja na modelu i na kodzie produkcyjnym.
**Wynik.** Obalone: zmiana składu docierała tylko do członków otwierających pokój, póki była świeża — w modelu wspólny klucz w ciągu doby miało 3–9 % członków, a ginęło 29–55 % wiadomości pokoju. Kryterium spełnił dopiero wariant dopisany po pierwszych liczbach (post hoc): 100 % i poniżej 0,5 %. Wdrożono go mimo to, a odstępstwo od własnej reguły zapisano na karcie; test na urządzeniach czeka. Znalezione i naprawione: przy otwarciu pokoju relay czytał jego rozmiar i skład; nadal widzi zmianę składu (100 % w modelu), a z licznika w nagłówku — ilu członków pisze.
**Dalej.** Ochrona przed powtórzeniem ramek z kluczami; poufność przyszła dla dystrybucji kluczy nadawcy; usunięty członek wciąż widzi, kiedy pokój jest aktywny.
**Konstrukcja: wstrzymana.**
**Status:** gojenie bez koordynatora i dostarczanie w tle w aplikacji; granice z punktu „Dalej" otwarte.

### 6. Kierunek 6 — zaprzeczalny magazyn z ukrytym wolumenem
**Pytanie.** Czy profil ukryty pozostaje niedowodliwy po miesiącach używania wobec kogoś, kto kopiuje pamięć telefonu i mierzy czas odblokowania?
**Stan techniki.** Ukryte wolumeny klasy VeraCrypt; przeciwnik z wieloma migawkami (Czeskis i in., 2008).
**Kryterium.** Bez hasła wabika detektor na jednej lub dwóch kopiach na poziomie przypadku; zero utraty danych w co najmniej 300 skryptowanych cyklach życia; czas odblokowania bez różnicy.
**Metoda.** 3 karty: kod produkcyjny magazynu w miesiącach symulowanego użycia, stoper na telefonie.
**Wynik.** Twierdzenie obalone: „nieodróżnialne na dysku" — po 30 dniach jedna kopia ujawniała profil ukryty w 69 % symulowanych telefonów z nieotwieranym wabikiem, dwie w 98–100 %; odblokowanie trwało około 1,1 s dłużej, a używanie wabika mogło nadpisać profil ukryty. Po przebudowie: 0 utraconych danych w 600 cyklach życia, 0 rozbieżności rozmiaru w 7200 migawkach, odblokowanie od −3 do +28 ms względem telefonu bez wabika. Predykcja zarejestrowana dla przebudowy chybiła — zmiana hasła miała własny podpis; ostatnią z dwóch dalszych poprawek sprawdzono testem, nie populacją.
**Dalej.** Z hasłem wabika w cudzych rękach dwie kopie nadal pokazują użycie profilu ukrytego; re-randomizacja bez klucza kosztuje dziś 14–40-krotność budżetu zapisu.
**Konstrukcja: wstrzymana.**
**Status:** w aplikacji, zmierzone w cyklu życia; granice przy przekazanym haśle wabika nazwane.

### 7. Kierunek 7 — warunkowy dostęp z kworum
**Pytanie.** Czy ocena warunków odblokowania — hasło, plik, link, kworum K-z-N, klucz sprzętowy — nie zdradza sekretu ani położenia?
**Stan techniki.** Podział sekretu Shamira nad GF(2⁸); warunki egzekwowane po stronie klienta.
**Kryterium.** Arytmetyka kworum z |t| ≤ 4,5 na telefonie; ocena warunku nie wysyła niczego poza Torem.
**Metoda.** Bez własnej karty: arytmetykę kworum zmierzyła karta kierunku 1, warunek położenia sprawdzono poza kartami.
**Wynik.** Obalone i naprawione: mnożenie w GF(2⁸) oparte na tablicach przeciekało (|t| do 1222); wersja bez gałęzi i tablic jest wyczerpująco równoważna na wszystkich 65 536 parach wejść. Wynik negatywny: warunek położenia usunięto, bo jego ocena wysyłała do Google okoliczne sieci Wi-Fi i komórkowe, poza Torem.
**Dalej.** Pomiar samego grafu warunków.
**Konstrukcja: wstrzymana.**
**Status:** blokada z dowolną kombinacją warunków w aplikacji; graf warunków bez karty pomiarowej.

### Korekty wpisu z 2026-07-10

- Metodyka, „weryfikacja jako testowalna własność": wektory sprawdzają poprawność, nie kanały boczne ani zachowanie w czasie — cztery prymitywy je przechodziły i przeciekały na telefonie, a magazyn wabika tracił dane.
- Kierunek 2, „Status: prace projektowe": dziś zbudowane, poza aplikacją; biblioteka natywna (FFI) nie była potrzebna do usunięcia zmierzonego wycieku.
- Kierunek 3, „stałą stopę Poissona": działa stała siatka z fazą losowaną na nowo przy każdej rotacji adresu. „Nigdy dokładnej długości" i „nieodróżnialnymi ramkami pozornymi": do 1 września nieprawdziwe dla pokoi i dużych ramek ruchu pozornego. „Każda persona na własnym obwodzie Tor": prawda, ale wspólny zegar urządzenia łączył persony. „pcap-diff": nie został wykonany; liczby o ruchu pochodzą z modelu.
- Kierunek 4, „relay nie zbatchuje adresów w »jedno urządzenie«" i „najwyżej jedno 15-minutowe okno": fałszywe wobec relaya, prawdziwe tylko wobec obserwatora z zewnątrz i złośliwego kontaktu. „Kursor po stronie klienta" i status „zaimplementowane i przetestowane": sam kursor łączył adresy rozmowy, a wiadomości do nieobecnego odbiorcy mogły ginąć; naprawione 17 września.
- Kierunek 5, „bez utraty własności bezpieczeństwa MLS": niespełnione w całości — granice wymienione w kierunku 5.
- Kierunek 6, „mechanizm zaimplementowany": tracił dane i był wykrywalny po 30 dniach; przebudowany 17 września.

**Status kierunku.** Zbudowane, lecz poza aplikacją: leczenie po kompromitacji i hybryda post-kwantowa. Otwarte wobec relaya: kanał czasu i licznik w nagłówku. Poza zasięgiem tej serii: niezależny przegląd protokołu i implementacji oraz pomiar na prawdziwym ruchu. Kolejny wpis opisze jedenaście kart z 20–29 września; bieżący stan prowadzi strona [ygoow.com/progress](https://ygoow.com/progress/).

---
---

# 🇩🇪 DEUTSCHE FASSUNG

## 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](https://ygoow.com/blog/2026-09-10-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.

- 37 Karten (24. Juli – 29. September), alle mit Stufe 2; die Ergebnisse von 11 davon, vom 20. bis 29. September, sind noch nicht veröffentlicht. Stufe 1 mit eigenem Commit vor der Messung haben 24, alle ab dem 6. September; die 13 früheren hielten Kriterien und Ergebnisse im selben Commit fest, sodass dort nur der Text der Karte die Reihenfolge belegt.
- Vorhersageregister (ab dem 3. September, 25 Karten): 199 Vorhersagen — 113 getroffen, 48 teilweise oder nur in der Richtung getroffen, 36 verfehlt, 2 nicht bewertbar; 19 dieser Karten enthalten einen Fehlschlag.
- Widerlegte Aussagen: 8 Sätze, die ygoow.com als Eigenschaft des Produkts veröffentlicht hatte und denen eine Karte widersprach; alle wurden zurückgezogen oder umgeschrieben (unten: „widerlegte Aussage"). Zwei weitere standen nur in internen Dokumenten.
- Nach Richtungen: 1 — 11, 2 — 4, 3 — 11, 4 — 3, 5 — 5, 6 — 3, 7 — 0.

**Regeln, die Fehlschläge erzwungen haben.**

- Zeit messen wir nur auf dem Zieltelefon und im Release-Build, und einen Negativbefund akzeptieren wir nur mit einer Positivkontrolle, die in derselben Sitzung angeschlagen hat: ML-KEM war auf dem Desktop unauffällig und zeigte auf dem Telefon 15,6 % Zeitdifferenz; ein Debug-Durchlauf sah nicht einmal das bekannte Leck.
- Der Gegner muss mindestens so stark sein wie der stärkste, der sich aus dem öffentlichen Protokoll bauen lässt: Ein schwächerer wählt die falsche Korrektur. Drei Vorhersagen zu seiner Stärke lagen alle in dieselbe Richtung daneben, um den Faktor 6–24.
- Vor der Registrierung einer Schwelle: Zufallsniveau, Erreichbarkeit der Schwelle und ein Fall, der von Hand durch den Mechanismus geführt wird — aus dem Randbereich der Verteilung.
- Verkehrszahlen stammen aus einem Modell des öffentlichen Protokolls und einer deklarierten Population, nicht aus mitgeschnittenem Tor-Verkehr.

### 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

- Methodik, „Verifikation als testbare Eigenschaft": Vektoren prüfen Korrektheit, nicht Seitenkanäle und nicht das Verhalten über die Zeit — vier Primitive bestanden sie und leckten auf dem Telefon, und der Decoy-Speicher verlor Daten.
- Richtung 2, „Status: Entwurf/Design": heute gebaut, außerhalb der App; eine native Bibliothek (FFI) war zur Beseitigung des gemessenen Lecks nicht nötig.
- Richtung 3, „konstante Poisson-Rate": In Betrieb ist ein festes Raster, dessen Phase bei jeder Adressrotation neu ausgelost wird. „Nie die exakte Länge" und „ununterscheidbaren Dummy-Frames": bis zum 1. September falsch für Räume und für große Cover-Frames. „Jede Persona auf einem eigenen Tor-Circuit": zutreffend, doch eine gemeinsame Geräteuhr verknüpfte die Personas. „pcap-Diff": nicht durchgeführt; die Verkehrszahlen stammen aus dem Modell.
- Richtung 4, „Adressen nicht zu ‚einem Gerät' bündeln" und „höchstens ein 15-Min-Fenster": gegenüber dem Relay falsch, zutreffend nur gegenüber einem Beobachter von außen und einem böswilligen Kontakt. „Cursor client-seitig" und der Status „implementiert und getestet": Der Cursor selbst verknüpfte die Adressen eines Gesprächs, und Nachrichten an abwesende Empfänger konnten verloren gehen; behoben am 17. September.
- Richtung 5, „ohne Verlust der MLS-Sicherheitseigenschaften": nicht vollständig erfüllt — die Grenzen stehen unter Richtung 5.
- Richtung 6, „Mechanismus implementiert": Er verlor Daten und war nach 30 Tagen erkennbar; am 17. September umgebaut.

**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](https://ygoow.com/progress/).

---
---

# 🇬🇧 ENGLISH VERSION

## Koch Laboratory — Ygoow: pre-registered measurement of our own security claims

The entry of 10 July 2026 ("Metadata-resistant, account-less communication") described seven research directions for a messenger with a deaf relay, without naming the product. The product is Ygoow (ygoow.com); the Android app has not been released yet. From 24 July to 29 September 2026 we turned its security claims into measurement cards. Below: the method, the counts, results already public on the product site, and corrections to the July entry. A summary of the method: [Measured, not assumed](https://ygoow.com/blog/2026-09-10-measured-not-assumed/).

**Method: the card in two stages.** Stage 1, written before the instrument runs: the question; the adversary — the strongest one we can build from the public protocol description; a population model with the chance level computed; criteria, numerical predictions, candidate fixes and a decision rule. Stage 2, the measurement: a null control (two samples of the same class) and a positive control (a known effect that must be detected in the same session); time and cost on the reference phone (ARM64, release build), traffic, storage and groups in simulation of the production code or of a model of it; a verdict on every criterion and every prediction, additions after the first numbers marked post hoc, deviations named. The practice tightened along the way: since 3 September every number has come from at least three runs or random seeds, and since 6 September stage 1 has gone into the repository in a commit of its own before the measurement.

**Counts (as of 29 September 2026).** A card is one protocol in the product's repository.

- 37 cards (24 July – 29 September), all with stage 2; the results of 11 of them, from 20–29 September, are not yet published. 24, all from 6 September on, have stage 1 in a commit of its own before the measurement; the 13 earlier ones recorded criteria and results in the same commit, so there only the card's text attests the order.
- Prediction ledger (from 3 September, 25 cards): 199 predictions — 113 held, 48 held in part or only in direction, 36 missed, 2 could not be assessed; 19 of these cards contain a miss.
- Claims overturned: 8 sentences that ygoow.com had published as a property of the product and that a card contradicted; all were withdrawn or rewritten (marked "claim overturned" below). Two more stood only in internal documents.
- By direction: 1 — 11, 2 — 4, 3 — 11, 4 — 3, 5 — 5, 6 — 3, 7 — 0.

**Rules the misses forced.**

- We measure timing only on the target phone, in a release build, and accept a negative only with a positive control that fired in the same session: ML-KEM was clean on the desktop and showed a 15.6 % timing difference on the phone; a debug run did not see even the known leak.
- The adversary must be at least as strong as the strongest one that can be built from the public protocol: a weaker one picks the wrong fix. Three predictions of its strength all missed in the same direction, by a factor of 6–24.
- Before registering a threshold: the chance level, whether the threshold is attainable at that level, and one case walked by hand through the mechanism — taken from the tail of the distribution.
- Traffic numbers come from a model of the public protocol and a declared population, not from captured Tor traffic.

### 1. Direction 1 — Post-compromise security without a stateful server: the primitives underneath
**Question.** Do encryption, signature, key agreement and key derivation leak a secret through their running time on the phone?
**State of the art.** TVLA and dudect (Welch's t-test), RFC 8032, NIST SP 800-38D, RFC 9106, zxcvbn.
**Criterion.** |t| ≤ 4.5 in every run with a clean null control and a positive control that fired; output matching the test vectors.
**Method.** 11 cards (2 from 20–29 September), phone and simulation; none measured the healing after compromise itself.
**Result.** Refuted and fixed: Ed25519 (|t| = 60 and 71, natively 2.6 and 1.6), the quorum arithmetic (direction 7) and AES-GCM (an effect of about 1.4 %, visible only with a local clock; published before the fix, natively 24 of 24 readings at noise level). X25519 clean. Claim overturned: "an honest strength meter" — it overstated the strength of "word + digits + symbol" passwords by a median of 45 bits; 97 % of them passed the backup file's check, today 0.3–0.6 %. The change of 28 August, made without a card (less memory in the backup's key derivation), was overturned by a card two days later.
**Next.** The Double Ratchet in the app, which also closes the forward-secrecy gap; an unexplained timing anomaly in the third-party SHA3 library.
**Construction: withheld.**
**Status:** primitives measured and in the app; post-compromise security built and verified against test vectors, outside the app.

### 2. Direction 2 — Post-quantum hybrid (X25519 + ML-KEM)
**Question.** Does the hybrid protect the first message against someone who records today and breaks X25519 later, and does it fit the key exchange between contacts?
**State of the art.** FIPS 203, Signal PQXDH, X25519MLKEM768, KyberSlash.
**Criterion.** The post-quantum half holds after X25519 is broken; an invitation fits one QR code at error-correction level M; |t| ≤ 4.5 on the phone.
**Method.** 4 cards: analysis of the production flows, the app's QR library, timing on the phone.
**Result.** Claim overturned, published in July: the post-quantum key derived from the X25519 secret was meant to protect the first message, but two supported flows expose public keys from which that secret can be computed once X25519 is broken; since 23 August the post-quantum key no longer depends on X25519. Refuted: a single QR code is too dense — it takes a split QR code, NFC or a link. Refuted and fixed: a secret-dependent division in our own ML-KEM implementation — 15.6 % on the phone (|t| = 339), after the fix |t| = 3.9.
**Next.** Wiring into live conversations and into the contact code; until then, "harvest now, decrypt later" is not covered in the app.
**Status:** built and pinned to the published accumulated test vectors, outside the app.

### 3. Direction 3 — Metadata-resistance layer
**Question.** What does the relay read from the size, rhythm and number of frames without seeing content or the IP address?
**State of the art.** Loopix, Tor's netflow padding, the likelihood-ratio test, mutual information.
**Criterion.** Size carries ≤ 0.5 bit about message length and depends on public parameters only; no frame is "certainly real" by its size; grouping a device's addresses stays at ≤ 2× chance.
**Method.** 11 cards (4 from 20–29 September): a model of the public protocol on the production code paths, a relay with a clock as the adversary.
**Result.** Claims overturned and fixed: "never the exact length" (rooms unpadded; today 0.043 bit of length) and "indistinguishable decoy frames" (always the smallest class; today 0.0002 bit in size, 0.0018 bit in spacing). Claim overturned: "the relay cannot tell when you send" — cover traffic hides messages, not sessions, and is off by default; without it the relay keeps 98.5 % of the information about when someone talks. Claims overturned: "the relay cannot batch addresses into one device" and "personas do not reveal a shared device" — a likelihood-ratio adversary groups a device's addresses 85–90 % of the time after one 15-minute epoch and 99.8 % within 30 minutes. Found: the unencrypted message counter in the header links a conversation across the address rotation 81–89 % of the time among 20 active conversations.
**Next.** Two measured designs for closing the timing channel await a decision; header encryption in progress; a measurement on real traffic.
**Construction: withheld.**
**Status:** size padding and optional cover traffic in the app; the timing channel and the counter open.

### 4. Direction 4 — Address-less rendezvous with epoch rotation
**Question.** Does rotating the conversation address roughly every 15 minutes break the continuity visible to the relay without losing messages?
**State of the art.** Tor onion services, store-and-forward delivery, linkability across identifier changes.
**Criterion.** Loss of messages to an absent recipient ≤ 0.1 %; consecutive epochs of a conversation linked through the cursor alone ≤ 1 %.
**Method.** 3 cards (2 from 20–29 September): simulation with and without background delivery.
**Result.** Refuted and fixed: in the default configuration, messages to someone absent for more than 15–30 minutes could be lost without notice (57–58 % in the model; today 0 %), and the catch-up cursor itself linked a conversation's addresses (100 %; today 0 %).
**Next.** The results of two cards of 22 September — in a later entry.
**Construction: withheld.**
**Status:** address rotation and trail-free catch-up in the app; against the relay, rotation alone is not enough (direction 3).

### 5. Direction 5 — Coordinator-free healing of group epochs
**Question.** Does a membership change reach every member, including absent ones, and what does the relay learn about the group from control frames?
**State of the art.** MLS (RFC 9420) with an ordering server, Sender Keys.
**Criterion.** At least 99 % of members on the same key within 24 h with background delivery (95 % without); loss of room messages ≤ 0.5 % in every seed.
**Method.** 5 cards (3 from 20–29 September): simulation on a model and on the production code.
**Result.** Refuted: a change reached only members who opened the room while it was fresh — in the model, 3–9 % of members shared the key within a day, and 29–55 % of room messages were lost. The criterion was met only by a variant added after the first numbers (post hoc): 100 % and under 0.5 %. It was deployed anyway, and the deviation from our own rule is recorded on the card; the on-device test is pending. Found and fixed: when a room was opened, the relay read its size and membership; it still sees that the membership changes (100 % in the model) and, from the header counter, how many members are writing.
**Next.** Protection against replayed key frames; forward secrecy for distributing sender keys; a removed member still sees when the room is active.
**Construction: withheld.**
**Status:** coordinator-free healing and background delivery in the app; the limits under "Next" remain open.

### 6. Direction 6 — Deniable store with a hidden volume
**Question.** Does the hidden profile stay unprovable after months of use — against someone who copies the phone's storage and times the unlock?
**State of the art.** VeraCrypt-class hidden volumes; the multi-snapshot adversary (Czeskis et al., 2008).
**Criterion.** Without the decoy password, a detector on one or two copies performs at chance level; no data loss in at least 300 scripted lifetimes; no difference in unlock time.
**Method.** 3 cards: the production storage code over months of simulated use, a stopwatch on the phone.
**Result.** Claim overturned: "indistinguishable on disk" — after 30 days a single copy revealed the hidden profile on 69 % of simulated phones whose decoy was never opened, two copies on 98–100 %; unlocking took about 1.1 s longer, and using the decoy could overwrite the hidden profile. After the redesign: 0 data lost in 600 lifetimes, 0 size mismatches in 7,200 snapshots, unlock within −3 to +28 ms of a phone without a decoy. The prediction registered for the redesign missed — a password change had a signature of its own; the last of two further fixes was checked by a test, not on the population.
**Next.** With the decoy password in someone else's hands, two copies still show use of the hidden profile; re-randomisation without the key costs 14–40 times the write budget today.
**Construction: withheld.**
**Status:** in the app, measured over the lifecycle; the limits with a surrendered decoy password are named.

### 7. Direction 7 — Conditional access with quorum
**Question.** When the unlock conditions — password, file, link, K-of-N quorum, hardware key — are evaluated, do the secret and the location stay hidden?
**State of the art.** Shamir secret sharing over GF(2⁸); conditions enforced on the client.
**Criterion.** Quorum arithmetic with |t| ≤ 4.5 on the phone; evaluating a condition sends nothing outside Tor.
**Method.** No card of its own: the quorum arithmetic was measured by a card of direction 1, the location condition was examined outside the cards.
**Result.** Refuted and fixed: the table-based multiplication in GF(2⁸) leaked (|t| up to 1222); the branch-free, table-free version is exhaustively equivalent over all 65,536 input pairs. Negative result: the location condition was removed because evaluating it sent the surrounding Wi-Fi and cell networks to Google, outside Tor.
**Next.** A measurement of the condition graph itself.
**Construction: withheld.**
**Status:** the lock with any combination of conditions in the app; the condition graph without a measurement card.

### Corrections to the entry of 2026-07-10

- Method, "verification as a testable property": vectors check correctness, not side channels and not behaviour over time — four primitives passed them and leaked on the phone, and the decoy store lost data.
- Direction 2, "Status: design": built today, outside the app; a native library (FFI) was not needed to remove the measured leak.
- Direction 3, "a constant Poisson rate": what runs is a fixed grid whose phase is drawn afresh at every address rotation. "Never the exact length" and "indistinguishable decoy frames": false until 1 September for rooms and for large cover frames. "Each persona rides its own Tor circuit": true, but a shared device clock linked the personas. "pcap diff": not carried out; traffic numbers come from the model.
- Direction 4, "cannot batch addresses into 'one device'" and "at most one 15-min window": false against the relay, true only against an outside observer and a malicious contact. "The client carries the cursor" and the status "implemented and tested": the cursor itself linked a conversation's addresses, and messages to absent recipients could be lost; fixed on 17 September.
- Direction 5, "no loss of MLS security properties": not met in full — the limits are listed under direction 5.
- Direction 6, "mechanism implemented": it lost data and was detectable after 30 days; redesigned on 17 September.

**Status of the direction.** Built, but outside the app: post-compromise security and the post-quantum hybrid. Open towards the relay: the timing channel and the header counter. Outside this series: an independent review of protocol and implementation, and a measurement on real traffic. A later entry will describe the eleven cards from 20–29 September; the current state is kept on [ygoow.com/progress](https://ygoow.com/progress/).