Koch Laboratory

Ygoow: prerejestrowany pomiar własnych twierdzeń o bezpieczeństwie

Kontynuuje wpis z 2026-07-10, już z nazwą produktu. Od lipca do września 2026 twierdzenia Ygoow o bezpieczeństwie zamieniano w dwuetapowe karty — najpierw kryteria i predykcje, potem pomiar — na docelowym telefonie albo w symulacji: 37 kart (24 z rejestracją zapisaną przed pomiarem), 199 predykcji w rejestrze, z czego 36 chybionych, osiem opublikowanych twierdzeń obalonych i wycofanych oraz korekty nieaktualnych stwierdzeń wpisu lipcowego. Konstrukcje wstrzymane; wyniki o ruchu pochodzą z modelu, nie z przechwyconego ruchu Tor.

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.

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.

Reguły wymuszone przez chybienia.

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

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.

Dowód czasu

Ten tekst został zahaszowany i ostemplowany przy publikacji. Do sprawdzenia potrzebne są oba pliki: stempel dowodzi, że w tamtej chwili istniał dokładnie jeden ciąg bajtów, a tym ciągiem jest wyłącznie źródło poniżej. Każda późniejsza zmiana przesuwa skrót i zrywa zgodność — i o to właśnie chodzi.

· @529.57 · 2026-W40

SHA-256 ostemplowanego tekstu: e7809aa121bebb53a42cf9597437a55ba01b50a48bcf2a28cf4c049345f99442

Sprawdzenie: ots verify <dowód> --file <źródło>