# Koch Laboratory - Czas jako dowód, po raz trzeci: strażnicy z własnym zegarem i granice reguły „2 z 3” (Sigelith) · Forschungsportfolio / Portfolio badawcze / Research Portfolio > **Zasada publikacji.** Formaty, klucze publiczne dziennika i strażników, specyfikacje oraz programy sprawdzające są jawne - dowód, którego nie da się sprawdzić bez pytania operatora, nie jest dowodem. Wstrzymane pozostają wyłącznie klucze prywatne i szczegóły operacyjne infrastruktury. > **Zasada uczciwości.** Ten wpis kontynuuje i koryguje wpis z 2026-10-01, który pozostaje niezmieniony. Budowę systemu i procedurę dla biegłego opisuje raport techniczny z 9 października 2026 (DOI 10.5281/zenodo.23265547); tutaj jest zapis badawczy: co miało działać, co sprawdzono, co się nie utrzymało i gdzie leżą granice. --- --- # 🇵🇱 WERSJA POLSKA ## Koch Laboratory - czas jako dowód, po raz trzeci: strażnicy z własnym zegarem i granice reguły „2 z 3” Wpis z 2026-10-01 („Czas jako dowód, raz jeszcze”) zamykał kierunek 1 otwartym pytaniem: czy stan dziennika powinny podpisywać niezależne strony, tak aby sam klucz operatora - skompromitowany albo źle skonfigurowany - nie wystarczał do przedstawienia przekonującej alternatywnej historii. Pięć dni później działali dwaj strażnicy. Ten wpis opisuje, co sprawdzają i gdzie leżą granice reguły „2 z 3”, jak usługa przestała stemplować przy nieznanym błędzie zegara, co od tamtej pory okazało się błędem i które stwierdzenia wpisu z 2026-10-01 są już nieaktualne. Pełny opis budowy i procedurę, którą biegły przeprowadza sam, zawiera raport techniczny z 9 października 2026 ([doi.org/10.5281/zenodo.23265547](https://doi.org/10.5281/zenodo.23265547)). **Co tu jest badaniem, a co nie.** Podpisy świadków nad stanem dziennika to dojrzały wzorzec logów przejrzystości; uwierzytelniona synchronizacja czasu (NTS, RFC 8915), zasada wstrzymania znaczników po utracie synchronizacji i dowód pracy sekwencyjnej z kierunku 4 też nie są nasze. Treścią badawczą są granice - co dokładnie poświadcza podpis strażnika, ile ochrony daje reguła „2 z 3”, gdy dwa z trzech kluczy ma operator, i co z tego widzi osoba sprawdzająca stempel - oraz to, co zawiodło. Teza dowodowa pozostaje bez zmian: stempel wykazuje, że plik o danym odcisku istniał już w chwili stempla - nie to, że wcześniej nie istniał, ani kto jest jego autorem. **Metodyka.** Jak w reszcie laboratorium: problem → stan techniki → falsyfikowalne kryterium → metoda → wynik (potwierdzony, obalony albo częściowy, z warunkami brzegowymi) → następny krok. Wynik negatywny jest wynikiem. Liczby z testów są oznaczone jako takie. ### 1. Kierunek 1 - strażnicy, którzy sprawdzają czas wpisów, a nie tylko spójność dziennika **Problem.** Po incydencie z kluczem (wpis z 2026-10-01, kierunek 1) zaufanie przeszło z podpisu na kopie i kotwice. Kopie są jednak bierne - przechowują, ale niczego nie sprawdzają przed przyjęciem - a między stemplem a najbliższą kotwicą w Bitcoinie mija do około doby. W tym oknie czas wpisu był wyłącznie słowem operatora: nikt poza nim nie obserwował dziennika na bieżąco. **Stan techniki (publikowany).** Świadkowie kontrasygnujący stan drzewa w logach przejrzystości (specyfikacje C2SP `tlog-cosignature` i `tlog-witness`, baza sum kontrolnych modułów Go, Sigstore) i kolektywne podpisy świadków (CoSi; Syta i in., IEEE S&P 2016). Analiza progów dla świadków (N. Möller, projekt Sigsum, 2023): reguła *k* z *n* chroni przed rozbieżnymi wersjami historii przy *f* nieuczciwych podpisujących tylko wtedy, gdy 2*k* > *n* + *f*. Świadek w tym wzorcu poświadcza przede wszystkim spójność kolejnych stanów drzewa i chwilę, w której je zobaczył; czasu zapisanego w poszczególnych wpisach zwykle nie sprawdza. **Kryterium (falsyfikowalne).** (1) Strażnik podpisuje tylko to, co sam sprawdził: łańcuch skrótów, drzewo globalne przeliczone od zera i czas każdego nowego wpisu względem własnego zegara - z tolerancją ±30 s, przy czym wpis nie może być starszy niż poprzednia obserwacja strażnika; (2) serwer usługi nie może sam wytworzyć podpisu strażnika ani podsunąć mu niczego do podpisania; (3) program sprawdzający pokazuje stempel jako potwierdzony tylko wtedy, gdy sam sprawdził co najmniej dwa z trzech podpisów. Kryterium obala podpis strażnika nad stanem, którego strażnik nie sprawdził, podpisany wpis z czasem wstecznym ponad tolerancję albo potwierdzenie pokazane bez dwóch sprawdzonych podpisów. **Metoda.** Od 6 października 2026 dwa programy-strażnicy działają na osobnych maszynach i kontach: jeden w AWS (funkcja Lambda we Frankfurcie, klucz w module sprzętowym AWS KMS), prowadzony przez operatora Sigelith, drugi u Konverii - niezależnej firmy z Krakowa, bez powiązań osobowych i kapitałowych z operatorem, która publikuje też aplikacje Sigelith na Androida. Co minutę każdy strażnik sam pobiera publiczny dziennik, sprawdza łańcuch i czas nowych wpisów, przelicza drzewo RFC 9162 i podpisuje to, co zobaczył (`sigelith-cosign-v1`: rozmiar i korzeń drzewa, ostatni wpis, własny czas i czas poprzedniej obserwacji). Strażnik nie ma żadnego wejścia z zewnątrz. Serwer nie ma kluczy strażników - przechowuje i udostępnia ich podpisy, a podpis niezgodny z własnym drzewem zapisuje jako niezgodny. Każda nieprawidłowość - przerwany łańcuch, czas cofający się, wpis datowany wstecz albo z przyszłości - zatrzymuje strażnika do ręcznej decyzji jego operatora; strażnik nigdy nie podpisuje „mimo wszystko”, a ostatni podpis każdego strażnika jest publiczny, więc przerwę widać. Stempel uznaje się za potwierdzony, gdy popierają go dowolne dwa z trzech podpisów: klucza dziennika (kwit) i dwóch strażników. Program strażnika jest publiczny, z powtarzalną kompilacją, opisem protokołu, wektorem testowym i testami tych zatrzymań ([github.com/DeiFlagellum/sigelith-cosigner](https://github.com/DeiFlagellum/sigelith-cosigner), Apache-2.0). Od 19 października strona weryfikacji (`/proof/`) i biblioteka PHP dla wtyczek same liczą regułę „2 z 3”: kwit, ścieżkę RFC 9162 do podpisanego korzenia i podpisy strażników, kluczami wpisanymi w kod; strona pokazuje „N z 3 podpisów sprawdzonych w tej przeglądarce” wyłącznie z własnych obliczeń, a niezgodny podpis zawsze na czerwono. Od 26 października Sigelith Backup zapisuje podpisy strażników na płycie archiwalnej i sprawdza je bez sieci; jego weryfikator jest przeniesieniem modułu strony i używa tych samych wektorów testowych. **Wynik.** Potwierdzony w zakresie kryterium. 6 października o 20:13 UTC wpis nr 300 miał trzy z trzech podpisów, każdy sprawdzony osobno; 19 października strona w przeglądarce oraz biblioteka PHP na żywym API pokazały trzy z trzech (testy na wspólnych wektorach: 14 przypadków w JavaScripcie, 1724 sprawdzenia w PHP 7.4 i 8.3). Okno czasu wpisu skurczyło się z około doby (kotwice) do około minuty (obserwacje strażników) - np. wpis nr 320, zapisany o 18:48:03,213 UTC, strażnik w AWS zobaczył między 18:47:05 a 18:48:05, a strażnik Konverii między 18:47:31 a 18:48:31. Warunki brzegowe: (a) **dwa z trzech podpisujących systemów prowadzi operator** - klucz dziennika i strażnika w AWS; serwer usługi nie ma dostępu do konta AWS, ale operator jako jego właściciel - tak. Z warunku 2*k* > *n* + *f* dla układu 2 z 3 wynika *f* = 0: reguła nie toleruje żadnego zmawiającego się podpisującego, a operator sam ją spełnia. „2 z 3” chroni więc przed włamaniem do jednego systemu i przed błędem konfiguracji takim jak wrześniowy; wobec operatora niezależni są strażnik Konverii, Bitcoin, bank i archiwa; (b) niezależność Konverii i to, że klucza z AWS KMS nie da się skopiować, są oświadczeniami, których nie da się sprawdzić kryptograficznie; (c) okno strażnika pochodzi z jego własnego zegara - jest tak dobre jak ten zegar i nie jest niezależnym źródłem czasu; (d) strona `/proof/` liczy w przeglądarce, ale jej kod dostarcza serwer operatora - niezależnym sprawdzeniem pozostaje procedura z raportu, a klient desktopowy, który sprawdza dowody bez serwera, podpisów strażników jeszcze nie sprawdza; (e) wpisy sprzed 6 października nie mają okna strażników; (f) strażnik zatrzymuje się po każdej nieprawidłowości, a dostępności strażników dotąd nie mierzyliśmy. **Następny krok.** Zmierzyć dostępność strażników z ich publicznych podpisów; sprawdzanie podpisów strażników w kliencie desktopowym. Otwarte pozostaje, czy i kiedy dołączą kolejni niezależni strażnicy: z tego samego warunku wynika (obliczenie własne), że operator z dwoma kluczami przestaje sam spełniać regułę, gdy niezależnych strażników jest co najmniej trzech, a próg wynosi 4 z 5. **Status:** wdrożone od 6 października 2026; sprawdzanie „2 z 3” w przeglądarce i w PHP od 19 października, w Sigelith Backup od 26 października; granice (a)-(f) obowiązują. ### 2. Kierunek 2 - usługa przestaje stemplować, gdy nie zna błędu swojego zegara **Problem.** Zapisany czas wpisu to wskazanie zegara serwera. Wpis z 2026-10-01 prostował, że dotychczasowy pomiar odchyłki był jednym nieuwierzytelnionym zapytaniem SNTP do jednego serwera - sygnałem stanu, nie dowodem. Do 6 października nic też nie wstrzymywało stemplowania, gdy zegar odbiegał: wpis z błędnym czasem wykryłyby najwyżej kotwice, z dokładnością do godzin. **Stan techniki (publikowany).** Uwierzytelniona synchronizacja czasu NTS (RFC 8915); norma ETSI EN 319 421 przewiduje wstrzymanie wydawania znaczników czasu po utracie synchronizacji z UTC (Sigelith tej normie nie podlega i nie deklaruje z nią zgodności); RFC 3161 - czas znacznika jest wart tyle, ile zegar urzędu. **Kryterium (falsyfikowalne).** Nowy wpis i nowy checkpoint powstają wyłącznie wtedy, gdy ostatni udany pomiar zegara ma najwyżej 15 minut, a odchyłka nie przekracza 0,25 s; w przeciwnym razie usługa odmawia (kod 503, `clock_untrusted`) i nie zapisuje niczego. Obala je jeden wpis zapisany poza tymi warunkami. **Metoda.** Od 6 października 2026 usługa co 5 minut sama mierzy odchyłkę swojego zegara przez NTS względem serwerów PTB (Physikalisch-Technische Bundesanstalt, niemiecki krajowy instytut metrologii), a gdy oba są nieosiągalne - względem Netnodu. Każda próba jest zapisywana; ostatni pomiar jest publiczny (`/api/health/`, strona `/evidence/`), a certyfikat PDF wpisu podaje ostatni pomiar sprzed wpisu („Server clock”). Wpisów zapisanych wcześniej blokada nie zmienia. **Wynik.** Wdrożone; pomiary punktowe: 6 października odchyłka poniżej 0,1 ms przy opóźnieniu 9 ms, 9 października 0,2 ms. Warunki brzegowe: (a) pomiar jest oświadczeniem operatora o jego własnym pomiarze, nie potwierdzeniem PTB - sama PTB zastrzega, że NTS nie daje prawnie wiążącej informacji o czasie; (b) historia pomiarów nie jest publiczna, a to, że blokada działa, jest słowem operatora - nie ma publicznego wskaźnika jej stanu; (c) atakujący na łączu może przesunąć pomiar najwyżej o połowę czasu przejścia w obie strony, w praktyce o milisekundy; (d) niezależnie od tego pomiaru czas wpisu sprawdzają strażnicy (kierunek 1, z tolerancją ±30 s) i kotwice. **Następny krok.** Ustalić, czy i jak publikować historię pomiarów i stan blokady, tak by dało się je sprawdzić bez pytania operatora. **Status:** wdrożone od 6 października 2026. ### 3. Kierunek 3 - wyniki negatywne i poprawki od 1 października **(a) Dziennik dostępu pozwalał powiązać stempel z siecią i przeglądarką.** Czas wpisu jest publiczny z dokładnością do mikrosekundy, a dziennik dostępu serwera WWW zapisywał czas zapytania, sieć /24 i nagłówek User-Agent; serwer aplikacji zapisywał do tego pełne adresy zapytań razem z odciskami. Po czasie dało się więc dopasować stempel do sieci i przeglądarki osoby, która go wykonała. Wynik negatywny: brak konta i adresu e-mail nie wystarczał, żeby stempla nie dało się z kimś powiązać. Poprawka z 9 października 2026: dziennik dostępu bez adresu IP, portu i nagłówków zapytania (ze strony odsyłającej zostaje tylko domena), serwer aplikacji bez dziennika dostępu, filtr wycinający z komunikatów każdy 64-znakowy odcisk, liczniki limitów zapytań wyłącznie w pamięci procesu; po wdrożeniu sprawdzone. Warunek brzegowy: operator, który kontroluje serwer, może te ustawienia w każdej chwili zmienić - kto potrzebuje anonimowości także wobec niego, powinien stemplować przez Tor (połączenia przez Tor nie trafiają do żadnego dziennika dostępu). **(b) Biblioteka PHP brała odmowę za stempel.** Biblioteka PHP dla wtyczek nie sprawdzała kodu odpowiedzi HTTP: odpowiedzi 400, 429 i 503 dawały wynik wyglądający na udany stempel. Błąd ważył tym więcej, że od 6 października usługa celowo odpowiada kodem 503, gdy nie ufa swojemu zegarowi (kierunek 2). Znaleziony w przeglądzie wewnętrznym 6 października, poprawiony 19 października: każda odpowiedź 4xx i 5xx jest zgłaszana jako błąd z kodem HTTP. To ta sama klasa błędu co w przeglądzie klienta desktopowego (wpis z 2026-10-01, kierunek 5) - pokazanie jako wykonanego czegoś, czego nie wykonano. **(c) Zdania mocniejsze niż system - poprawione po recenzji zewnętrznej z 7 października.** Recenzent zewnętrzny odtworzył rdzeń kryptograficzny z samej publicznej specyfikacji, a zarazem wskazał zdania, które obiecywały więcej, niż system zapewnia. Poprawione tego samego dnia: (1) zamiast „sprawdzisz, nie ufając nikomu - także nam” strona mówi „sprawdzisz, nie wierząc nam na słowo”: weryfikator w przeglądarce pochodzi z naszego serwera, a niezależnie sprawdza się programem Sigelith Desktop o otwartym kodzie albo procedurą dla biegłego; (2) Bitcoin i archiwa każdy sprawdzi bez nas, ale potwierdzenie przelewu z korzeniem wydajemy na prośbę, a bank potwierdza je na wniosek sądu; (3) GitHub zniknął z listy „stron, których nie kontrolujemy” - wydania leżą na naszym koncie; (4) przy Konverii dopisano, że to niezależna firma bez powiązań osobowych i kapitałowych z operatorem; (5) specyfikacja mówi wprost, że zapis wpisu może się opóźnić tylko w stronę późniejszą, nigdy wcześniejszą, i że serwer nie ma kluczy strażników. **Status:** poprawki wdrożone. ### 4. Kierunek 4 - Klepsydra: dowód minimalnego upływu czasu (w toku) **Problem.** Kotwice dają górną granicę czasu, a blok Bitcoina nazwany w checkpoincie - dolną. Nic nie dowodzi natomiast, ile czasu upłynęło między dwoma zdarzeniami w dzienniku, niezależnie od zegarów - ani naszego, ani strażników. **Stan techniki (publikowany).** Dowody pracy sekwencyjnej (B. Cohen, K. Pietrzak, *Simple Proofs of Sequential Work*, EUROCRYPT 2018). Funkcje opóźniające z weryfikacją (VDF) nie istnieją z samych funkcji skrótu w modelu wyroczni losowej; ceną konstrukcji opartej wyłącznie na skrótach jest to, że sprawdzenie gwarantuje wykonanie tylko części pracy. **Kryterium (falsyfikowalne).** Między dwoma zdarzeniami upłynął co najmniej czas wynikający z liczby wykonanych kroków - przy jawnym założeniu *k*, że nikt nie liczy tej pracy więcej niż *k* razy szybciej niż zmierzony prover. Obala je sprzęt liczący szybciej niż założone *k*. **Metoda.** Od 19 października 2026 serwer usługi liczy Klepsydrę (Sigelith Hourglass) - dowód pracy sekwencyjnej Cohena i Pietrzaka na SHA-256, w odcinkach, na jednym rdzeniu procesora. Ziarno każdego odcinka wchłania świeży blok Bitcoina i ostatni checkpoint Sigelith, a odcinek łączy się z korzeniem poprzedniego; rekord odcinka jest stemplowany w dzienniku i potwierdzany przez strażników. Konstrukcję Cohena i Pietrzaka implementujemy wiernie; nowe są system i pomiary. Specyfikacja, implementacja referencyjna i kod są publiczne ([github.com/DeiFlagellum/sigelith-hourglass](https://github.com/DeiFlagellum/sigelith-hourglass), Apache-2.0). **Wynik.** Jeszcze brak - faza 0 to 30-dniowy pomiar na serwerze produkcyjnym (genesis ostemplowany jako wpis nr 453, koniec 18 listopada 2026). Do jego końca *k* = 20 jest założeniem, a nic z fazy 0 nie trafia na certyfikaty. Warunki brzegowe podane z góry: (a) wyłącznie dolne granice, i to skromne - przy *k* = 20 tydzień odcinków dowodziłby około 6 godzin; (b) Klepsydrę liczy jeden operator - zegar można zatrzymać; podrobienie go po cichu wykluczają dopiero publicznie dostępne odcinki, bo wtedy dwa różne korzenie jednego odcinka zobaczy każdy; (c) pliki odcinków nie są jeszcze publikowane, więc dziś osoba trzecia sprawdzi tylko, że w dzienniku zapisano odciski rekordów odcinków, a nie sam dowód pracy. **Następny krok.** Po 18 listopada: analiza pomiaru, publiczna notatka, parametry i genesis wersji 1 - w osobnym wpisie. **Status:** w toku (faza 0). ### Stan kroków zapowiedzianych 1 października - **Kierunek 1 - podpisy niezależnych świadków:** wykonane (kierunek 1 tego wpisu), z granicą (a). - **Kierunek 2 - samodzielny skrypt weryfikacyjny dla osób trzecich:** wykonane inaczej, niż zapowiedziano - zamiast skryptu procedura krok po kroku standardowymi narzędziami (sha256sum, Python, OpenSSL) na stronie specyfikacji (od 6 października) i w raporcie technicznym (rozdz. 5). - **Kierunek 3 - czy wyciąg bankowy daje osobie trzeciej coś ponad numer referencji:** nierozstrzygnięte; strona mówi dziś wprost, że potwierdzenie przelewu wydajemy na prośbę, a bank potwierdza je na wniosek sądu. - **Kierunek 4 - porównywanie daty wpisu z datą wersji kopii i szyfrowanie spisu wersji:** otwarte. - **Kierunek 5 - wspólne wektory testowe:** wspólny zestaw powstał dla sprawdzania „2 z 3” (strona, biblioteka PHP, serwer i Sigelith Backup sprawdzają się na tych samych wektorach); dopisanie przypadków manipulacji z przeglądu klienta - otwarte. ### Korekty wpisu z 2026-10-01 Wpis z 2026-10-01 pozostaje niezmieniony. Poniżej jego stwierdzenia, które są nieaktualne albo nie były dokładne. **Kierunek 1, „Następny krok”: podpisy niezależnych świadków jako otwarte pytanie.** Nieaktualne od 6 października 2026 (kierunek 1 tego wpisu). **Kierunek 1, warunki brzegowe: „rotacja wymaga dziś zmiany listy kluczy w trzech miejscach”.** Nieaktualne: klucze publiczne są dziś wpisane także w moduł strony `/proof/`, w bibliotekę PHP i w Sigelith Backup, więc rotacja wymaga zmian w większej liczbie miejsc i nowych wydań. **Kierunek 2, Metoda i „Status kierunku”: GitHub wśród kopii u stron trzecich.** Niedokładne: wydania w GitHubie są niezmienne, ale leżą na koncie operatora, a całe repozytorium można usunąć. GitHub przechowuje kopię poza naszą infrastrukturą, nie poza naszą kontrolą. **Kierunek 2, warunek brzegowy (c): „świadków kontrasygnujących nie ma”.** Nieaktualne od 6 października 2026. **Kierunek 2, warunek brzegowy (f): strony w przeglądarce biorą część dotyczącą logu z odpowiedzi serwera.** Nieaktualne dla strony `/proof/`: od 19 października sama liczy kwit, ścieżkę do podpisanego korzenia i podpisy strażników. **Kierunek 3, Metoda: „usługa co pięć minut mierzy też swój offset względem zewnętrznego serwera i publikuje wynik”.** Niedokładne od 6 października: publikowany wynik to dziś ostatni uwierzytelniony pomiar względem PTB, który blokuje nowe wpisy (kierunek 2 tego wpisu); historia pomiarów nie jest publiczna. **„Status kierunku”: „Najbliższe kroki: samodzielny skrypt weryfikacyjny dla osób trzecich i rozstrzygnięcia z kierunku 4”.** Skrypt zastąpiła procedura dla biegłego (patrz „Stan kroków”); rozstrzygnięcia z kierunku 4 pozostają otwarte. Kapsuły czasowe i protokół dowodu doręczenia nadal czekają na osobny wpis. **Status kierunku.** Stan dziennika potwierdzają od 6 października dwaj strażnicy z własnymi zegarami, a od 19 października strona weryfikacji i biblioteka PHP liczą regułę „2 z 3” same. Usługa przestaje stemplować, gdy nie zna błędu swojego zegara. Najbliższe kroki: pomiar dostępności strażników, sprawdzanie ich podpisów w kliencie desktopowym, wyniki fazy 0 Klepsydry (po 18 listopada 2026) i decyzja o publikacji historii pomiarów zegara. --- --- # 🇩🇪 DEUTSCHE FASSUNG ## Koch Laboratory - Zeit als Beweis, zum dritten Mal: Mitunterzeichner mit eigener Uhr und die Grenzen der Regel „2 aus 3“ Der Eintrag vom 2026-10-01 („Zeit als Beweis, neu betrachtet“) schloss Richtung 1 mit einer offenen Frage ab: ob den Zustand des Logs unabhängige Parteien signieren sollten, damit der Schlüssel des Betreibers allein - kompromittiert oder falsch konfiguriert - nicht genügt, um eine überzeugende alternative Geschichte vorzulegen. Fünf Tage später liefen zwei Mitunterzeichner. Dieser Eintrag beschreibt, was sie prüfen und wo die Grenzen der Regel „2 aus 3“ liegen, wie der Dienst aufhörte, bei unbekanntem Uhrenfehler zu stempeln, was sich seither als Fehler erwiesen hat und welche Aussagen des Eintrags vom 2026-10-01 inzwischen veraltet sind. Die vollständige Beschreibung des Aufbaus und das Verfahren, das ein Sachverständiger selbst durchführt, enthält der technische Bericht vom 9. Oktober 2026 ([doi.org/10.5281/zenodo.23265547](https://doi.org/10.5281/zenodo.23265547)). **Was hier Forschung ist und was nicht.** Signaturen von Zeugen über dem Zustand des Logs sind ein ausgereiftes Muster der Transparenz-Logs; authentifizierte Zeitsynchronisation (NTS, RFC 8915), der Grundsatz, die Ausgabe von Zeitstempeln nach einem Verlust der Synchronisation auszusetzen, und der Nachweis sequenzieller Arbeit aus Richtung 4 stammen ebenfalls nicht von uns. Forschungsgegenstand sind die Grenzen - was genau die Signatur eines Mitunterzeichners bezeugt, wie viel Schutz die Regel „2 aus 3“ bietet, wenn der Betreiber zwei der drei Schlüssel hält, und was davon eine Person sieht, die einen Stempel prüft - sowie das, was versagt hat. Die Beweisaussage bleibt unverändert: Ein Stempel zeigt, dass eine Datei mit einem gegebenen Fingerabdruck zum Zeitpunkt des Stempels bereits existierte - nicht, dass sie vorher nicht existierte, und nicht, wer ihr Urheber ist. **Methodik.** Wie im übrigen Labor: Problem → Stand der Technik → falsifizierbares Kriterium → Methode → Ergebnis (bestätigt, widerlegt oder teilweise, mit Randbedingungen) → nächster Schritt. Ein negatives Ergebnis ist ein Ergebnis. Zahlen aus Tests sind als solche gekennzeichnet. ### 1. Richtung 1 - Mitunterzeichner, die die Zeit der Einträge prüfen und nicht nur die Konsistenz des Logs **Problem.** Nach dem Schlüsselvorfall (Eintrag vom 2026-10-01, Richtung 1) verlagerte sich das Vertrauen von der Signatur auf die Kopien und die Anker. Die Kopien sind jedoch passiv - sie bewahren auf, prüfen aber vor der Annahme nichts -, und zwischen einem Stempel und dem nächsten Anker in Bitcoin vergeht bis zu etwa ein Tag. In diesem Fenster war die Zeit eines Eintrags allein das Wort des Betreibers: Niemand außer ihm beobachtete das Log laufend. **Stand der Technik (veröffentlicht).** Zeugen, die in Transparenz-Logs den Baumzustand gegenzeichnen (die C2SP-Spezifikationen `tlog-cosignature` und `tlog-witness`, die Prüfsummendatenbank der Go-Module, Sigstore), und kollektive Zeugensignaturen (CoSi; Syta et al., IEEE S&P 2016). Schwellenanalyse für Zeugen (N. Möller, Projekt Sigsum, 2023): Eine Regel *k* aus *n* schützt bei *f* unredlichen Unterzeichnern nur dann vor voneinander abweichenden Versionen der Geschichte, wenn 2*k* > *n* + *f*. Ein Zeuge bezeugt in diesem Muster vor allem die Konsistenz aufeinanderfolgender Baumzustände und den Zeitpunkt, zu dem er sie gesehen hat; die in den einzelnen Einträgen erfasste Zeit prüft er in der Regel nicht. **Kriterium (falsifizierbar).** (1) Ein Mitunterzeichner signiert nur, was er selbst geprüft hat: die Hash-Kette, den von Grund auf nachgerechneten globalen Baum und die Zeit jedes neuen Eintrags gegenüber seiner eigenen Uhr - mit einer Toleranz von ±30 s, wobei ein Eintrag nicht älter sein darf als die vorige Beobachtung des Mitunterzeichners; (2) der Server des Dienstes kann weder selbst eine Signatur eines Mitunterzeichners erzeugen noch ihm etwas zum Signieren unterschieben; (3) ein Prüfprogramm zeigt einen Stempel nur dann als bestätigt an, wenn es selbst mindestens zwei der drei Signaturen geprüft hat. Widerlegt wird das Kriterium durch die Signatur eines Mitunterzeichners über einem Zustand, den er nicht geprüft hat, durch einen signierten Eintrag, der über die Toleranz hinaus zurückdatiert ist, oder durch eine Bestätigung, die ohne zwei geprüfte Signaturen angezeigt wird. **Methode.** Seit dem 6. Oktober 2026 laufen zwei Mitunterzeichner-Programme auf getrennten Maschinen und Konten: eines bei AWS (eine Lambda-Funktion in Frankfurt, der Schlüssel in einem Hardwaremodul von AWS KMS), betrieben vom Sigelith-Betreiber, das andere bei Konveria - einem unabhängigen Unternehmen in Krakau ohne personelle oder kapitalmäßige Verbindungen zum Betreiber, das auch die Android-Apps von Sigelith veröffentlicht. Jede Minute lädt jeder Mitunterzeichner das öffentliche Log selbst herunter, prüft die Kette und die Zeit neuer Einträge, berechnet den RFC-9162-Baum neu und signiert, was er gesehen hat (`sigelith-cosign-v1`: Größe und Wurzel des Baums, letzter Eintrag, eigene Zeit und Zeit der vorigen Beobachtung). Ein Mitunterzeichner nimmt keinerlei Eingaben von außen entgegen. Der Server hat keine Schlüssel der Mitunterzeichner - er speichert ihre Signaturen und stellt sie bereit, und eine Signatur, die nicht zu seinem eigenen Baum passt, erfasst er als nicht übereinstimmend. Jede Unregelmäßigkeit - eine unterbrochene Kette, eine zurücklaufende Zeit, ein zurückdatierter oder in die Zukunft datierter Eintrag - hält den Mitunterzeichner bis zu einer manuellen Entscheidung seines Betreibers an; ein Mitunterzeichner signiert nie „trotzdem“, und die letzte Signatur jedes Mitunterzeichners ist öffentlich, sodass eine Unterbrechung sichtbar ist. Ein Stempel gilt als bestätigt, wenn ihn zwei beliebige der drei Signaturen stützen: die des Log-Schlüssels (die Quittung) und die der beiden Mitunterzeichner. Das Mitunterzeichner-Programm ist öffentlich, mit reproduzierbarem Build, Protokollbeschreibung, Testvektor und Tests für diese Stopps ([github.com/DeiFlagellum/sigelith-cosigner](https://github.com/DeiFlagellum/sigelith-cosigner), Apache-2.0). Seit dem 19. Oktober werten die Prüfseite (`/proof/`) und die PHP-Bibliothek für Plugins die Regel „2 aus 3“ selbst aus: die Quittung, den RFC-9162-Pfad zu einer signierten Wurzel und die Signaturen der Mitunterzeichner, mit im Code hinterlegten Schlüsseln; die Seite zeigt „N von 3 Signaturen in diesem Browser geprüft“ ausschließlich auf Grundlage eigener Berechnungen an und eine nicht übereinstimmende Signatur immer in Rot. Seit dem 26. Oktober schreibt Sigelith Backup die Signaturen der Mitunterzeichner auf eine Archiv-Disc und prüft sie ohne Netz; sein Prüfprogramm ist eine Portierung des Moduls der Seite und nutzt dieselben Testvektoren. **Ergebnis.** Im Rahmen des Kriteriums bestätigt. Am 6. Oktober um 20:13 UTC hatte Eintrag Nr. 300 drei von drei Signaturen, jede einzeln geprüft; am 19. Oktober zeigten die Seite im Browser und die PHP-Bibliothek an der Live-API drei von drei (Tests an gemeinsamen Vektoren: 14 Fälle in JavaScript, 1724 Prüfungen in PHP 7.4 und 8.3). Das Zeitfenster eines Eintrags schrumpfte von etwa einem Tag (Anker) auf etwa eine Minute (Beobachtungen der Mitunterzeichner) - z. B. sah der Mitunterzeichner bei AWS den Eintrag Nr. 320, erfasst um 18:48:03,213 UTC, zwischen 18:47:05 und 18:48:05 und der Mitunterzeichner von Konveria zwischen 18:47:31 und 18:48:31. Randbedingungen: (a) **Zwei der drei signierenden Systeme werden vom Betreiber betrieben** - der Log-Schlüssel und der Mitunterzeichner bei AWS; der Server des Dienstes hat keinen Zugriff auf das AWS-Konto, der Betreiber als dessen Inhaber aber schon. Für die Anordnung 2 aus 3 ergibt sich aus der Bedingung 2*k* > *n* + *f* der Wert *f* = 0: Die Regel toleriert keinen Unterzeichner, der sich mit anderen abspricht, und der Betreiber erfüllt sie allein. „2 aus 3“ schützt also vor einem Einbruch in ein einzelnes System und vor einem Konfigurationsfehler wie dem im September; vom Betreiber unabhängig sind der Mitunterzeichner von Konveria, Bitcoin, die Bank und die Archive; (b) dass Konveria unabhängig ist und dass sich der Schlüssel nicht aus AWS KMS kopieren lässt, sind Angaben, die sich kryptografisch nicht prüfen lassen; (c) das Fenster eines Mitunterzeichners stammt von seiner eigenen Uhr - es ist so gut wie diese Uhr und keine unabhängige Zeitquelle; (d) die Seite `/proof/` rechnet im Browser, ihren Code liefert aber der Server des Betreibers - die unabhängige Prüfung bleibt das Verfahren aus dem Bericht, und der Desktop-Client, der Beweise ohne den Server prüft, prüft die Signaturen der Mitunterzeichner noch nicht; (e) Einträge vor dem 6. Oktober haben kein Fenster der Mitunterzeichner; (f) ein Mitunterzeichner hält nach jeder Unregelmäßigkeit an, und die Verfügbarkeit der Mitunterzeichner haben wir bisher nicht gemessen. **Nächster Schritt.** Messung der Verfügbarkeit der Mitunterzeichner anhand ihrer öffentlichen Signaturen; Prüfung der Signaturen der Mitunterzeichner im Desktop-Client. Offen bleibt, ob und wann weitere unabhängige Mitunterzeichner hinzukommen: Aus derselben Bedingung folgt (eigene Berechnung), dass ein Betreiber mit zwei Schlüsseln die Regel nicht mehr allein erfüllt, wenn es mindestens drei unabhängige Mitunterzeichner gibt und die Schwelle bei 4 aus 5 liegt. **Status:** umgesetzt seit dem 6. Oktober 2026; Prüfung „2 aus 3“ im Browser und in PHP seit dem 19. Oktober, in Sigelith Backup seit dem 26. Oktober; die Grenzen (a)-(f) gelten. ### 2. Richtung 2 - der Dienst stellt das Stempeln ein, wenn er den Fehler seiner Uhr nicht kennt **Problem.** Die erfasste Zeit eines Eintrags ist die Angabe der Serveruhr. Der Eintrag vom 2026-10-01 stellte richtig, dass die bisherige Messung der Abweichung eine einzelne, nicht authentifizierte SNTP-Abfrage an einen einzigen Server war - ein Zustandssignal, kein Beweis. Bis zum 6. Oktober hielt zudem nichts das Stempeln an, wenn die Uhr abwich: Einen Eintrag mit falscher Zeit hätten höchstens die Anker erkannt, auf Stunden genau. **Stand der Technik (veröffentlicht).** Authentifizierte Zeitsynchronisation mit NTS (RFC 8915); die Norm ETSI EN 319 421 sieht vor, die Ausgabe von Zeitstempeln nach einem Verlust der Synchronisation mit UTC auszusetzen (Sigelith unterliegt dieser Norm nicht und erklärt keine Konformität mit ihr); RFC 3161 - die Zeit eines Zeitstempels ist so viel wert wie die Uhr der Stelle. **Kriterium (falsifizierbar).** Ein neuer Eintrag und ein neuer Checkpoint entstehen nur dann, wenn die letzte erfolgreiche Messung der Uhr höchstens 15 Minuten alt ist und die Abweichung 0,25 s nicht überschreitet; andernfalls lehnt der Dienst ab (Code 503, `clock_untrusted`) und erfasst nichts. Widerlegt wird es durch einen einzigen Eintrag, der außerhalb dieser Bedingungen erfasst wurde. **Methode.** Seit dem 6. Oktober 2026 misst der Dienst alle 5 Minuten selbst die Abweichung seiner Uhr über NTS gegenüber den Servern der PTB (Physikalisch-Technische Bundesanstalt, das nationale Metrologieinstitut Deutschlands), und wenn beide nicht erreichbar sind - gegenüber Netnod. Jeder Versuch wird erfasst; die letzte Messung ist öffentlich (`/api/health/`, Seite `/evidence/`), und das PDF-Zertifikat eines Eintrags nennt die letzte Messung vor dem Eintrag („Server clock“). Früher erfasste Einträge ändert die Sperre nicht. **Ergebnis.** Umgesetzt; punktuelle Messungen: am 6. Oktober eine Abweichung unter 0,1 ms bei einer Verzögerung von 9 ms, am 9. Oktober 0,2 ms. Randbedingungen: (a) Die Messung ist eine Angabe des Betreibers über seine eigene Messung, keine Bestätigung der PTB - die PTB weist selbst darauf hin, dass NTS keine rechtsverbindliche Zeitinformation liefert; (b) die Historie der Messungen ist nicht öffentlich, und dass die Sperre funktioniert, ist das Wort des Betreibers - einen öffentlichen Indikator ihres Zustands gibt es nicht; (c) ein Angreifer auf dem Übertragungsweg kann die Messung höchstens um die Hälfte der Umlaufzeit verschieben, in der Praxis um Millisekunden; (d) unabhängig von dieser Messung prüfen die Mitunterzeichner (Richtung 1, mit einer Toleranz von ±30 s) und die Anker die Zeit eines Eintrags. **Nächster Schritt.** Klären, ob und wie die Historie der Messungen und der Zustand der Sperre veröffentlicht werden sollen, sodass sie sich ohne Rückfrage beim Betreiber prüfen lassen. **Status:** umgesetzt seit dem 6. Oktober 2026. ### 3. Richtung 3 - negative Ergebnisse und Korrekturen seit dem 1. Oktober **(a) Das Zugriffsprotokoll erlaubte es, einen Stempel mit einem Netz und einem Browser zu verknüpfen.** Die Zeit eines Eintrags ist auf die Mikrosekunde genau öffentlich, und das Zugriffsprotokoll des Webservers erfasste die Zeit der Anfrage, das /24-Netz und den User-Agent-Header; der Anwendungsserver erfasste zusätzlich die vollständigen Anfrage-URLs samt Fingerabdrücken. Im Nachhinein ließ sich ein Stempel also dem Netz und dem Browser der Person zuordnen, die ihn ausgeführt hatte. Negatives Ergebnis: Das Fehlen eines Kontos und einer E-Mail-Adresse reichte nicht aus, um zu verhindern, dass sich ein Stempel mit jemandem verknüpfen ließ. Korrektur vom 9. Oktober 2026: Zugriffsprotokoll ohne IP-Adresse, Port und Anfrage-Header (von der verweisenden Seite bleibt nur die Domain), Anwendungsserver ohne Zugriffsprotokoll, ein Filter, der jeden 64-stelligen Fingerabdruck aus Meldungen herausschneidet, Zähler der Anfragelimits ausschließlich im Prozessspeicher; nach der Umsetzung geprüft. Randbedingung: Der Betreiber, der den Server kontrolliert, kann diese Einstellungen jederzeit ändern - wer Anonymität auch ihm gegenüber braucht, sollte über Tor stempeln (Verbindungen über Tor landen in keinem Zugriffsprotokoll). **(b) Die PHP-Bibliothek hielt eine Ablehnung für einen Stempel.** Die PHP-Bibliothek für Plugins prüfte den HTTP-Statuscode nicht: Antworten mit 400, 429 und 503 ergaben ein Ergebnis, das wie ein erfolgreicher Stempel aussah. Der Fehler wog umso schwerer, als der Dienst seit dem 6. Oktober bewusst mit dem Code 503 antwortet, wenn er seiner Uhr nicht traut (Richtung 2). Gefunden bei einer internen Durchsicht am 6. Oktober, behoben am 19. Oktober: Jede Antwort mit 4xx und 5xx wird als Fehler mit dem HTTP-Code gemeldet. Das ist dieselbe Fehlerklasse wie bei der Durchsicht des Desktop-Clients (Eintrag vom 2026-10-01, Richtung 5) - etwas als ausgeführt anzuzeigen, was nicht ausgeführt wurde. **(c) Sätze, die stärker waren als das System - korrigiert nach der externen Begutachtung vom 7. Oktober.** Der externe Gutachter reproduzierte den kryptografischen Kern allein anhand der öffentlichen Spezifikation und wies zugleich auf Sätze hin, die mehr versprachen, als das System gewährleistet. Am selben Tag korrigiert: (1) „Überprüfbar, ohne jemandem vertrauen zu müssen - auch uns nicht“ wurde durch „Überprüfbar, ohne uns aufs Wort glauben zu müssen“ ersetzt: Das Prüfprogramm im Browser kommt von unserem Server, unabhängig prüft man mit dem quelloffenen Programm Sigelith Desktop oder mit dem Verfahren für Sachverständige; (2) Bitcoin und die Archive kann jeder ohne uns prüfen, die Bestätigung der Überweisung mit der Wurzel geben wir aber auf Anfrage heraus, und die Bank bestätigt sie auf Ersuchen eines Gerichts; (3) GitHub steht nicht mehr auf der Liste der „Parteien, die wir nicht kontrollieren“ - die Releases liegen in unserem Konto; (4) bei Konveria wurde ergänzt, dass es sich um ein unabhängiges Unternehmen ohne personelle oder kapitalmäßige Verbindungen zum Betreiber handelt; (5) die Spezifikation sagt ausdrücklich, dass sich die Erfassung eines Eintrags nur zu einem späteren Zeitpunkt hin verzögern kann, nie zu einem früheren, und dass der Server keine Schlüssel der Mitunterzeichner hat. **Status:** Korrekturen umgesetzt. ### 4. Richtung 4 - Hourglass: ein Nachweis der mindestens verstrichenen Zeit (in Arbeit) **Problem.** Die Anker liefern eine Obergrenze der Zeit, der in einem Checkpoint genannte Bitcoin-Block eine Untergrenze. Nichts belegt dagegen, wie viel Zeit zwischen zwei Ereignissen im Log verstrichen ist, unabhängig von Uhren - weder von unserer noch von denen der Mitunterzeichner. **Stand der Technik (veröffentlicht).** Nachweise sequenzieller Arbeit (B. Cohen, K. Pietrzak, *Simple Proofs of Sequential Work*, EUROCRYPT 2018). Verifizierbare Verzögerungsfunktionen (VDF) lassen sich im Random-Oracle-Modell nicht allein aus Hashfunktionen konstruieren; der Preis einer Konstruktion, die ausschließlich auf Hashes beruht, besteht darin, dass die Prüfung nur die Ausführung eines Teils der Arbeit garantiert. **Kriterium (falsifizierbar).** Zwischen zwei Ereignissen ist mindestens die Zeit verstrichen, die sich aus der Zahl der ausgeführten Schritte ergibt - unter der offen genannten Annahme *k*, dass niemand diese Arbeit mehr als *k*-mal schneller berechnet als der gemessene Prover. Widerlegt wird es durch Hardware, die schneller rechnet als das angenommene *k*. **Methode.** Seit dem 19. Oktober 2026 berechnet der Server des Dienstes Sigelith Hourglass - einen Nachweis sequenzieller Arbeit nach Cohen und Pietrzak auf SHA-256, in Abschnitten, auf einem einzigen Prozessorkern. In den Startwert jedes Abschnitts fließen ein frischer Bitcoin-Block und der letzte Checkpoint von Sigelith ein, und jeder Abschnitt knüpft an die Wurzel des vorigen an; der Datensatz des Abschnitts wird im Log gestempelt und von den Mitunterzeichnern bestätigt. Die Konstruktion von Cohen und Pietrzak setzen wir getreu um; neu sind das System und die Messungen. Spezifikation, Referenzimplementierung und Code sind öffentlich ([github.com/DeiFlagellum/sigelith-hourglass](https://github.com/DeiFlagellum/sigelith-hourglass), Apache-2.0). **Ergebnis.** Noch keines - Phase 0 ist eine 30-tägige Messung auf dem Produktivserver (Genesis gestempelt als Eintrag Nr. 453, Ende am 18. November 2026). Bis zu ihrem Ende ist *k* = 20 eine Annahme, und nichts aus Phase 0 gelangt auf die Zertifikate. Vorab genannte Randbedingungen: (a) ausschließlich Untergrenzen, und zwar bescheidene - bei *k* = 20 würde eine Woche an Abschnitten etwa 6 Stunden belegen; (b) Hourglass wird von einem einzigen Betreiber berechnet - die Uhr lässt sich anhalten; eine unbemerkte Fälschung schließen erst öffentlich zugängliche Abschnitte aus, weil dann jeder zwei verschiedene Wurzeln eines Abschnitts sehen würde; (c) die Dateien der Abschnitte werden noch nicht veröffentlicht, sodass ein Dritter heute nur prüfen kann, dass im Log die Fingerabdrücke der Abschnittsdatensätze erfasst wurden, nicht aber den Nachweis der Arbeit selbst. **Nächster Schritt.** Nach dem 18. November: Auswertung der Messung, eine öffentliche Notiz, Parameter und Genesis der Version 1 - in einem eigenen Eintrag. **Status:** in Arbeit (Phase 0). ### Stand der Schritte, die am 1. Oktober angekündigt wurden - **Richtung 1 - Signaturen unabhängiger Zeugen:** umgesetzt (Richtung 1 dieses Eintrags), mit der Grenze (a). - **Richtung 2 - ein eigenständiges Prüfskript für Dritte:** anders umgesetzt als angekündigt - statt eines Skripts ein schrittweises Verfahren mit Standardwerkzeugen (sha256sum, Python, OpenSSL) auf der Spezifikationsseite (seit dem 6. Oktober) und im technischen Bericht (Kap. 5). - **Richtung 3 - ob ein Kontoauszug einem Dritten etwas über die Referenznummer hinaus gibt:** ungeklärt; die Website sagt heute ausdrücklich, dass wir die Bestätigung der Überweisung auf Anfrage herausgeben und die Bank sie auf Ersuchen eines Gerichts bestätigt. - **Richtung 4 - Vergleich des Eintragsdatums mit dem Datum der Sicherungsversion und Verschlüsselung des Versionsverzeichnisses:** offen. - **Richtung 5 - gemeinsame Testvektoren:** Für die Prüfung „2 aus 3“ entstand ein gemeinsamer Satz (die Seite, die PHP-Bibliothek, der Server und Sigelith Backup werden an denselben Vektoren geprüft); die Aufnahme der Manipulationsfälle aus der Durchsicht des Clients - offen. ### Korrekturen zum Eintrag vom 2026-10-01 Der Eintrag vom 2026-10-01 bleibt unverändert. Im Folgenden seine Aussagen, die veraltet sind oder nicht genau waren. **Richtung 1, „Nächster Schritt“: Signaturen unabhängiger Zeugen als offene Frage.** Veraltet seit dem 6. Oktober 2026 (Richtung 1 dieses Eintrags). **Richtung 1, Randbedingungen: „eine Rotation verlangt heute die Änderung der Schlüsselliste an drei Stellen“.** Veraltet: Die öffentlichen Schlüssel sind heute auch im Modul der Seite `/proof/`, in der PHP-Bibliothek und in Sigelith Backup hinterlegt, sodass eine Rotation Änderungen an mehr Stellen und neue Versionen verlangt. **Richtung 2, Methode und „Status der Richtung“: GitHub unter den Kopien bei Dritten.** Ungenau: Die Releases bei GitHub sind unveränderlich, liegen aber im Konto des Betreibers, und das ganze Repository lässt sich löschen. GitHub bewahrt eine Kopie außerhalb unserer Infrastruktur auf, nicht außerhalb unserer Kontrolle. **Richtung 2, Randbedingung (c): „gegenzeichnende Zeugen gibt es nicht“.** Veraltet seit dem 6. Oktober 2026. **Richtung 2, Randbedingung (f): Browserseiten übernehmen den Log-Teil aus der Serverantwort.** Veraltet für die Seite `/proof/`: Seit dem 19. Oktober berechnet sie die Quittung, den Pfad zur signierten Wurzel und die Signaturen der Mitunterzeichner selbst. **Richtung 3, Methode: „der Dienst misst außerdem alle fünf Minuten seinen Offset gegenüber einem externen Server und veröffentlicht das Ergebnis“.** Ungenau seit dem 6. Oktober: Das veröffentlichte Ergebnis ist heute die letzte authentifizierte Messung gegenüber der PTB, die neue Einträge sperrt (Richtung 2 dieses Eintrags); die Historie der Messungen ist nicht öffentlich. **„Status der Richtung“: „Nächste Schritte: ein eigenständiges Prüfskript für Dritte und die Entscheidungen aus Richtung 4“.** Das Skript wurde durch das Verfahren für Sachverständige ersetzt (siehe „Stand der Schritte“); die Entscheidungen aus Richtung 4 bleiben offen. Zeitkapseln und das Protokoll für Zustellnachweise warten weiterhin auf einen eigenen Eintrag. **Status der Richtung.** Den Zustand des Logs bestätigen seit dem 6. Oktober zwei Mitunterzeichner mit eigener Uhr, und seit dem 19. Oktober werten die Prüfseite und die PHP-Bibliothek die Regel „2 aus 3“ selbst aus. Der Dienst stellt das Stempeln ein, wenn er den Fehler seiner Uhr nicht kennt. Nächste Schritte: Messung der Verfügbarkeit der Mitunterzeichner, Prüfung ihrer Signaturen im Desktop-Client, die Ergebnisse der Phase 0 von Hourglass (nach dem 18. November 2026) und eine Entscheidung über die Veröffentlichung der Messhistorie der Uhr. --- --- # 🇬🇧 ENGLISH VERSION ## Koch Laboratory - time as evidence, a third look: cosigners with their own clocks and the limits of the “2 of 3” rule The entry of 2026-10-01 (“Time as evidence, revisited”) closed direction 1 with an open question: whether the state of the log should be signed by independent parties, so that the operator's key alone - compromised or misconfigured - is not enough to present a convincing alternative history. Five days later two cosigners were running. This entry describes what they check and where the limits of the “2 of 3” rule lie, how the service stopped stamping when the error of its clock is unknown, what has since turned out to be a mistake, and which statements of the entry of 2026-10-01 are now outdated. The full description of the design and the procedure that a court expert carries out alone are given in the technical report of 9 October 2026 ([doi.org/10.5281/zenodo.23265547](https://doi.org/10.5281/zenodo.23265547)). **What is research here and what is not.** Witness signatures over the state of the log are a mature transparency-log pattern; authenticated time synchronisation (NTS, RFC 8915), the rule of suspending time stamps after a loss of synchronisation and the proof of sequential work from direction 4 are not ours either. The research content is in the limits - what exactly a cosigner's signature attests, how much protection the “2 of 3” rule gives when the operator holds two of the three keys, and what of this a person checking a stamp sees - and in what failed. The evidentiary claim remains unchanged: a stamp shows that a file with a given fingerprint already existed at the moment of the stamp - not that it did not exist earlier, nor who its author is. **Method.** As in the rest of the laboratory: problem → state of the art → falsifiable criterion → method → result (confirmed, refuted or partial, with boundary conditions) → next step. A negative result is a result. Figures from tests are marked as such. ### 1. Direction 1 - cosigners that check the time of entries, not only the consistency of the log **Problem.** After the key incident (entry of 2026-10-01, direction 1), trust moved from the signature to the copies and the anchors. The copies, however, are passive - they store but check nothing before accepting - and up to about a day passes between a stamp and the nearest anchor in Bitcoin. In that window the time of an entry was solely the operator's word: nobody but the operator was observing the log on an ongoing basis. **State of the art (published).** Witnesses that cosign the tree state in transparency logs (the C2SP specifications `tlog-cosignature` and `tlog-witness`, the Go module checksum database, Sigstore) and collective witness signatures (CoSi; Syta et al., IEEE S&P 2016). Threshold analysis for witnesses (N. Möller, Sigsum project, 2023): a *k*-of-*n* rule protects against divergent versions of the history with *f* dishonest signers only if 2*k* > *n* + *f*. In this pattern a witness attests above all the consistency of successive tree states and the moment at which it saw them; it usually does not check the time recorded in individual entries. **Criterion (falsifiable).** (1) A cosigner signs only what it has checked itself: the hash chain, the global tree recomputed from scratch, and the time of each new entry against its own clock - with a tolerance of ±30 s, and no entry may be older than the cosigner's previous observation; (2) the service's server cannot itself produce a cosigner's signature or slip it anything to sign; (3) a verifying program shows a stamp as confirmed only when it has itself checked at least two of the three signatures. The criterion is refuted by a cosigner's signature over a state the cosigner did not check, a signed entry dated back beyond the tolerance, or a confirmation shown without two checked signatures. **Method.** Since 6 October 2026 two cosigner programs have been running on separate machines and accounts: one in AWS (a Lambda function in Frankfurt, the key in an AWS KMS hardware module), run by the Sigelith operator, the other at Konveria - an independent company in Kraków with no personal or capital ties to the operator, which also publishes the Sigelith Android apps. Every minute each cosigner fetches the public log itself, checks the chain and the time of new entries, recomputes the RFC 9162 tree and signs what it saw (`sigelith-cosign-v1`: tree size and root, last entry, its own time and the time of its previous observation). A cosigner takes no input of any kind from outside. The server holds no cosigner keys - it stores and serves their signatures, and records a signature that does not match its own tree as not matching. Any anomaly - a broken chain, time going backwards, a backdated entry or one dated in the future - stops the cosigner until a manual decision by its operator; a cosigner never signs “anyway”, and the latest signature of each cosigner is public, so an interruption is visible. A stamp counts as confirmed when any two of the three signatures support it: that of the log key (the receipt) and those of the two cosigners. The cosigner program is public, with a reproducible build, a protocol description, a test vector and tests of these stops ([github.com/DeiFlagellum/sigelith-cosigner](https://github.com/DeiFlagellum/sigelith-cosigner), Apache-2.0). Since 19 October the verification page (`/proof/`) and the PHP library for plugins compute the “2 of 3” rule themselves: the receipt, the RFC 9162 path to a signed root and the cosigners' signatures, with keys built into the code; the page shows “N of 3 signatures verified in this browser” solely from its own computations, and a mismatching signature always in red. Since 26 October Sigelith Backup writes the cosigners' signatures to an archive disc and checks them offline; its verifier is a port of the page's module and uses the same test vectors. **Result.** Confirmed within the criterion. On 6 October at 20:13 UTC entry no. 300 had three of three signatures, each checked separately; on 19 October the page in the browser and the PHP library showed three of three on the live API (tests on shared vectors: 14 cases in JavaScript, 1724 checks in PHP 7.4 and 8.3). The time window of an entry shrank from about a day (anchors) to about a minute (the cosigners' observations) - e.g. entry no. 320, recorded at 18:48:03.213 UTC, was seen by the AWS cosigner between 18:47:05 and 18:48:05 and by the Konveria cosigner between 18:47:31 and 18:48:31. Boundary conditions: (a) **two of the three signing systems are run by the operator** - the log key and the AWS cosigner; the service's server has no access to the AWS account, but the operator, as its owner, does. For a 2-of-3 setup, the condition 2*k* > *n* + *f* gives *f* = 0: the rule tolerates no colluding signer, and the operator satisfies it on its own. “2 of 3” therefore protects against a break-in into one system and against a configuration error like the one in September; independent of the operator are the Konveria cosigner, Bitcoin, the bank and the archives; (b) that Konveria is independent and that the key cannot be copied out of AWS KMS are statements that cannot be checked cryptographically; (c) a cosigner's window comes from its own clock - it is as good as that clock and is not an independent source of time; (d) the `/proof/` page computes in the browser, but its code is delivered by the operator's server - the procedure in the report remains the independent check, and the desktop client, which checks proofs without the server, does not yet check the cosigners' signatures; (e) entries made before 6 October have no cosigner window; (f) a cosigner stops after every anomaly, and so far we have not measured the cosigners' availability. **Next step.** Measuring the cosigners' availability from their public signatures; checking the cosigners' signatures in the desktop client. It remains open whether and when further independent cosigners will join: the same condition implies (our own calculation) that an operator with two keys stops satisfying the rule on its own when there are at least three independent cosigners and the threshold is 4 of 5. **Status:** implemented since 6 October 2026; “2 of 3” checking in the browser and in PHP since 19 October, in Sigelith Backup since 26 October; boundaries (a)-(f) apply. ### 2. Direction 2 - the service stops stamping when it does not know the error of its clock **Problem.** The recorded time of an entry is a reading of the server clock. The entry of 2026-10-01 pointed out, by way of correction, that the offset measurement used until then had been a single unauthenticated SNTP query to a single server - a health signal, not evidence. Nor, until 6 October, did anything halt stamping when the clock deviated: an entry with a wrong time would at most have been detected by the anchors, to within hours. **State of the art (published).** Authenticated time synchronisation with NTS (RFC 8915); the ETSI EN 319 421 standard provides for suspending the issuance of time stamps after synchronisation with UTC is lost (Sigelith is not subject to this standard and does not claim conformity with it); RFC 3161 - the time of a time stamp is worth as much as the authority's clock. **Criterion (falsifiable).** A new entry and a new checkpoint are created only when the last successful clock measurement is at most 15 minutes old and the offset does not exceed 0.25 s; otherwise the service refuses (code 503, `clock_untrusted`) and records nothing. A single entry recorded outside these conditions refutes it. **Method.** Since 6 October 2026 the service itself measures the offset of its clock every 5 minutes, over NTS, against the PTB servers (Physikalisch-Technische Bundesanstalt, Germany's national metrology institute), and when both are unreachable - against Netnod. Every attempt is recorded; the latest measurement is public (`/api/health/`, the `/evidence/` page), and the PDF certificate of an entry gives the last measurement before the entry (“Server clock”). The lock does not change entries recorded earlier. **Result.** Implemented; spot measurements: on 6 October an offset below 0.1 ms with a delay of 9 ms, on 9 October 0.2 ms. Boundary conditions: (a) the measurement is the operator's statement about its own measurement, not a confirmation by PTB - PTB itself cautions that NTS gives no legally binding information about time; (b) the history of measurements is not public, and that the lock works is the operator's word - there is no public indicator of its state; (c) an attacker on the path can shift the measurement by at most half the round-trip time, in practice by milliseconds; (d) independently of this measurement, the time of an entry is checked by the cosigners (direction 1, with a tolerance of ±30 s) and by the anchors. **Next step.** Establish whether and how to publish the history of measurements and the state of the lock so that they can be checked without asking the operator. **Status:** implemented since 6 October 2026. ### 3. Direction 3 - negative results and fixes since 1 October **(a) The access log made it possible to link a stamp to a network and a browser.** The time of an entry is public to the microsecond, and the web server's access log recorded the time of the request, the /24 network and the User-Agent header; the application server additionally recorded the full request URLs together with the fingerprints. After the fact, a stamp could therefore be matched to the network and browser of the person who made it. Negative result: the absence of an account and an e-mail address was not enough to keep a stamp from being linked to someone. Fix of 9 October 2026: an access log without IP address, port or request headers (only the domain of the referring page remains), an application server without an access log, a filter that cuts every 64-character fingerprint out of messages, rate-limit counters in process memory only; checked after deployment. Boundary condition: the operator, who controls the server, can change these settings at any time - anyone who needs anonymity towards the operator as well should stamp via Tor (connections via Tor do not end up in any access log). **(b) The PHP library mistook a refusal for a stamp.** The PHP library for plugins did not check the HTTP status code: responses 400, 429 and 503 gave a result that looked like a successful stamp. The error mattered all the more because since 6 October the service deliberately answers with code 503 when it does not trust its clock (direction 2). Found in an internal review on 6 October, fixed on 19 October: every 4xx and 5xx response is reported as an error carrying the HTTP code. This is the same class of error as in the review of the desktop client (entry of 2026-10-01, direction 5) - showing as done something that was not done. **(c) Sentences stronger than the system - corrected after the external review of 7 October.** The external reviewer reproduced the cryptographic core from the public specification alone and at the same time pointed out sentences that promised more than the system provides. Corrected the same day: (1) “Verifiable without trusting anyone - including us” was replaced by “Verifiable without taking our word for it”: the verifier in the browser comes from our server, and an independent check is made with the open-source Sigelith Desktop program or with the procedure for court experts; (2) anyone can check Bitcoin and the archives without us, but we provide the confirmation of the transfer carrying the root on request, and the bank confirms it at the request of a court; (3) GitHub is no longer on the list of “parties we do not control” - the releases are in our account; (4) where Konveria is mentioned, it was added that it is an independent company with no personal or capital ties to the operator; (5) the specification says explicitly that the recording of an entry can be delayed only towards a later time, never towards an earlier one, and that the server holds no cosigner keys. **Status:** fixes implemented. ### 4. Direction 4 - Hourglass: a proof of minimum elapsed time (in progress) **Problem.** The anchors give an upper bound on time, and the Bitcoin block named in a checkpoint a lower one. Nothing, however, proves how much time passed between two events in the log, independently of clocks - neither ours nor the cosigners'. **State of the art (published).** Proofs of sequential work (B. Cohen, K. Pietrzak, *Simple Proofs of Sequential Work*, EUROCRYPT 2018). Verifiable delay functions (VDFs) cannot be built from hash functions alone in the random oracle model; the price of a construction based solely on hashes is that verification guarantees only that a part of the work was done. **Criterion (falsifiable).** Between two events at least the time implied by the number of steps performed has passed - under the explicit assumption *k* that nobody computes this work more than *k* times faster than the measured prover. Hardware that computes faster than the assumed *k* refutes it. **Method.** Since 19 October 2026 the service's server has been computing Sigelith Hourglass - a Cohen-Pietrzak proof of sequential work on SHA-256, in segments, on a single processor core. The seed of each segment absorbs a fresh Bitcoin block and the latest Sigelith checkpoint, and each segment links to the root of the previous one; the segment's record is stamped in the log and confirmed by the cosigners. We implement the Cohen-Pietrzak construction faithfully; what is new is the system and the measurements. The specification, the reference implementation and the code are public ([github.com/DeiFlagellum/sigelith-hourglass](https://github.com/DeiFlagellum/sigelith-hourglass), Apache-2.0). **Result.** None yet - phase 0 is a 30-day measurement on the production server (genesis stamped as entry no. 453, ending on 18 November 2026). Until it ends, *k* = 20 is an assumption, and nothing from phase 0 goes onto certificates. Boundary conditions stated in advance: (a) lower bounds only, and modest ones - with *k* = 20 a week of segments would prove about 6 hours; (b) Hourglass is computed by a single operator - the clock can be stopped; forging it silently is ruled out only by publicly available segments, because then anyone would see two different roots of one segment; (c) the segment files are not published yet, so today a third party can check only that the fingerprints of the segment records were recorded in the log, not the proof of work itself. **Next step.** After 18 November: analysis of the measurement, a public note, the parameters and the genesis of version 1 - in a separate entry. **Status:** in progress (phase 0). ### Status of the steps announced on 1 October - **Direction 1 - signatures of independent witnesses:** done (direction 1 of this entry), with boundary (a). - **Direction 2 - a standalone verification script for third parties:** done differently than announced - instead of a script, a step-by-step procedure with standard tools (sha256sum, Python, OpenSSL) on the specification page (since 6 October) and in the technical report (section 5). - **Direction 3 - whether a bank statement gives a third party anything beyond the reference number:** unresolved; the website now says explicitly that we provide the confirmation of the transfer on request, and that the bank confirms it at the request of a court. - **Direction 4 - comparing the entry's date with the date of the backup version, and encrypting the version's file list:** open. - **Direction 5 - shared test vectors:** a shared set was created for “2 of 3” checking (the page, the PHP library, the server and Sigelith Backup are tested against the same vectors); adding the manipulation cases from the client review - open. ### Corrections to the entry of 2026-10-01 The entry of 2026-10-01 stays unchanged. Below are its statements that are outdated or were not accurate. **Direction 1, “Next step”: signatures of independent witnesses as an open question.** Outdated since 6 October 2026 (direction 1 of this entry). **Direction 1, boundary conditions: “a rotation today requires changing the key list in three places”.** Outdated: the public keys are now also built into the module of the `/proof/` page, the PHP library and Sigelith Backup, so a rotation requires changes in more places and new releases. **Direction 2, Method and “Status of the direction”: GitHub among the copies held by third parties.** Inaccurate: the releases on GitHub are immutable, but they sit in the operator's account, and the whole repository can be deleted. GitHub keeps a copy outside our infrastructure, not outside our control. **Direction 2, boundary condition (c): “there are no cosigning witnesses”.** Outdated since 6 October 2026. **Direction 2, boundary condition (f): the browser pages take the log part from the server's response.** Outdated for the `/proof/` page: since 19 October it computes the receipt, the path to the signed root and the cosigners' signatures itself. **Direction 3, Method: “the service also measures its own offset against an external server every five minutes and publishes the result”.** Inaccurate since 6 October: the published result is now the last authenticated measurement against PTB, which blocks new entries (direction 2 of this entry); the history of measurements is not public. **“Status of the direction”: “Next steps: a standalone verification script for third parties and the decisions from direction 4”.** The script was replaced by the procedure for court experts (see “Status of the steps”); the decisions from direction 4 remain open. Time capsules and the proof-of-delivery protocol are still waiting for a separate entry. **Status of the direction.** Since 6 October the state of the log has been confirmed by two cosigners with their own clocks, and since 19 October the verification page and the PHP library compute the “2 of 3” rule themselves. The service stops stamping when it does not know the error of its clock. Next steps: measuring the cosigners' availability, checking their signatures in the desktop client, the results of Hourglass phase 0 (after 18 November 2026) and a decision on publishing the history of clock measurements.