# Koch Laboratory — Linia TimeVault, rewizja: przeszłość poświadczona, przyszłość wymuszana przez zewnętrzne kworum czasu · Forschungsportfolio / Portfolio badawcze / Research Portfolio > **Zasada publikacji.** Publikujemy problem, stan techniki, kryterium, wynik i jego granice; konstrukcja rozwiązań pozostaje wstrzymana. Wpisy z blokadą czasową opisujemy wyłącznie na poziomie publicznej specyfikacji koperty `beattime-seal-v1`, a wiązanie z miejscem — wyłącznie jako własność wraz z jej granicami. > **Zasada uczciwości.** Wpis kontynuuje wpis z 2026-07-14 i niczego w nim nie zmienia: stwierdzenia, które przestały być aktualne, są wymienione w sekcji korekt, a nie poprawione w miejscu. --- --- # 🇵🇱 WERSJA POLSKA ## Koch Laboratory — linia TimeVault, rewizja: przeszłość poświadczona, przyszłość wymuszana przez zewnętrzne kworum czasu Wpis z 2026-07-14 zamykał się tezą, że znakowanie czasem dowodzi przeszłości, ale nie wymusza przyszłości. Od tamtej pory linia TimeVault wymusza przyszłość dla pojedynczych wpisów — zewnętrznym kworum czasu, nie obliczeniami — a warunek miejsca przeszedł z polityki aplikacji do wyprowadzenia klucza. **Metodyka.** Problem → stan techniki → falsyfikowalne kryterium → metoda → wynik z warunkami brzegowymi → następny krok. Konstrukcji tu nie opisujemy. ### 1. Kierunek 3 po rewizji: wymuszanie przyszłości przez zewnętrzne kworum czasu **Problem.** Wpis ma pozostać nieczytelny do wskazanej chwili — także dla właściciela, autora aplikacji i operatora usługi — bez względu na zegar urządzenia. **Stan techniki (publikowany).** Time-lock puzzles (Rivest–Shamir–Wagner, 1996) i VDF (Boneh i in., 2018) wymagają pracy sekwencyjnej, więc chwila otwarcia zależy od sprzętu; przy blokadzie czasowej wobec progowego beacona losowości (drand, tlock) zależy od podpisu publikowanego dopiero w danej rundzie — za cenę zaufania do beacona. **Kryterium (falsyfikowalne).** Przed wskazaną chwilą żaden pojedynczy posiadacz klucza — operator, autor aplikacji ani właściciel — nie otworzy wpisu, a zegar urządzenia nie ma znaczenia; potem wpis otwiera się z danych uwolnionych publicznie, a koperta z jednej implementacji formatu — w drugiej i odwrotnie. **Metoda.** Publiczny format koperty `beattime-seal-v1`: kworum złożone z publicznego beacona losowości, serwerów klucza operatorów i kodu odzyskiwania właściciela; wpis pozostaje w zaszyfrowanym sejfie. Interoperacyjność sprawdzana warstwami, w obu kierunkach: wobec biblioteki referencyjnej, rzeczywiście opublikowanego podpisu beacona i drugiej implementacji formatu. **Wynik.** Potwierdzony w zakresie kryterium dla pojedynczych wpisów w aplikacji mobilnej linii, także łącznie z warunkiem miejsca; wobec pytania z lipca — częściowy: zaufaną stronę zastąpiło kworum o niezależności organizacyjnej. **Granice.** - Niezależność operatorów jest organizacyjna, nie kryptograficzna: format nie odróżni dwóch udziałów jednego podmiotu od udziałów dwóch. Serwer klucza prowadzi obecnie publiczna usługa czasu laboratorium, więc przed autorem aplikacji chronią beacon i kod odzyskiwania u właściciela. - Łańcuch beacona może zniknąć; kod odzyskiwania kompensuje utratę jednego beacona, nie obu. - Kod odzyskiwania to statyczny sekret: kto ma go razem z udziałem operatora uwolnionym przed czasem — przez błąd, przymus albo zmowę — otworzy wpis wcześniej. - Zwolnienie w terminie wykonywane przez serwer lub oprogramowanie urządzenia pozostaje polityką; kworum obejmuje tylko wpisy w tym formacie. **Następny krok.** Więcej operatorów — odrębnych podmiotów na odrębnej infrastrukturze — by otwarcie przed czasem wymagało zmowy większej liczby stron. **Status:** zaimplementowane + testy interoperacyjności; puzzle i VDF — poza implementacją; wymuszanie bez zaufanych stron — pytanie otwarte. ### 2. Miejsce: od polityki aplikacji do wiązania kryptograficznego **Problem.** Warunek „otwórz tylko tutaj” sprawdzany przez aplikację po odszyfrowaniu jest polityką — omija go zmieniona aplikacja albo podstawiona lokalizacja. Tak działał warunek miejsca w linii TimeVault przed przeprojektowaniem. **Stan techniki (publikowany).** Geofencing jako kontrola dostępu w aplikacjach; geo-szyfrowanie, czyli lokalizacja jako wejście do wyprowadzenia klucza (Scott i Denning, 2003). **Kryterium (falsyfikowalne).** Poza miejscem klucz nie istnieje, więc nie ma czego odmówić; plik nie zawiera niczego o miejscu — ani współrzędnych, ani promienia, ani nawet informacji, że wiązanie jest użyte; kod odzyskiwania zastępuje miejsce, nigdy pozostałe czynniki. **Wynik.** Potwierdzony w zakresie kryterium, dla sejfu i dla pojedynczego wpisu; na urządzeniu wpis związany z miejscem odmówił otwarcia w innym mieście. Konstrukcji wiązania tu nie opisujemy. **Granice.** Miejsce ma małą entropię: wiązanie chroni przed kimś, kto ma kopię zapasową i nie wie, gdzie stanąć, ale słabo przed kimś, kto ma telefon i zna miasto właściciela — to czynnik dodatkowy, nie zamiennik silnego hasła. Bez miejsca i bez kodu odzyskiwania treść jest zamknięta na stałe. **Następny krok.** Pomiar efektywnej przestrzeni przeszukiwania dla napastnika znającego miasto; dziś ta granica jest opisana jakościowo, nie zmierzona. **Status:** zaimplementowane + testy, w tym na urządzeniu. ### 3. Wyniki negatywne i przeprojektowania od lipca - **Warunki dostępu w jawnym nagłówku.** We wcześniejszej wersji kontenera miejsce i data otwarcia leżały w nagłówku uwierzytelnionym, ale jawnym — kto miał plik, znał współrzędne, pod którymi sejf się otwiera. Przeniesiono je do części szyfrowanej. Lekcja: uwierzytelnione nie znaczy ukryte. - **Identyfikatory plików-czynników (kierunek 2).** Jawna część koperty zawierała identyfikatory plików-czynników w zadeklarowanej kolejności — wbrew wymaganiu z lipca i bez żadnej funkcji przy odzysku: posiadacz kontenera i plików-kandydatów mógł potwierdzić, które są czynnikami i w jakiej kolejności. Wyciek usunięto. **Status:** naprawione i pokryte testami. ### Korekty wpisu z 2026-07-14 - **Kierunek 3, status „kryptograficzne wymuszanie przyszłości — otwarte pytanie badawcze”.** Nieaktualne w części: wymuszanie przyszłości istnieje dla pojedynczych wpisów (sekcja 1). Otwarte pozostaje wymuszanie bez zaufanych stron; teza, że polityka urządzenia pozostaje polityką, obowiązuje bez zmian. - **Kierunek 3, znakowanie przeszłości („zaimplementowane + testy”).** W usłudze webowej linii status ten dotyczył własnego formatu znacznika opartego na sekrecie operatora; taki znacznik świadczy o zaufaniu do operatora, nie o czasie, a w tej usłudze nie miał też zewnętrznej kotwicy. Format wycofano; znaczniki tej usługi powstają teraz w publicznej usłudze czasu laboratorium (wpis „Czas jako uzgodniona jednostka i jako dowód”) z zaślepionego odcisku pliku. - **Kierunek 2, wymaganie, by koperty nie zdradzały, które pliki są czynnikami.** W chwili publikacji implementacja go nie spełniała (sekcja 3); naprawione. - **Kierunek 1 — doprecyzowanie.** Pytanie badawcze — by serwis w żadnym momencie, także podczas zwolnienia, nie był w stanie samodzielnie niczego odszyfrować — opisuje cel, nie własność implementacji webowej: jej strona bezpieczeństwa stwierdza, że przy odblokowanej sesji serwer przetwarza dane w pamięci, i nazywa to zaufanym oknem sesji, nie „zero-knowledge”. Testowane kryterium obowiązuje bez zmian. **Status kierunku.** Przeszłość poświadcza osobna, publicznie weryfikowalna usługa czasu; przyszłość wymusza dla pojedynczych wpisów kworum, które zaufanie rozkłada, a nie usuwa; wiązanie z miejscem jest częścią klucza. Żadna z opisanych konstrukcji nie przeszła zewnętrznego audytu. --- --- # 🇩🇪 DEUTSCHE FASSUNG ## Koch Laboratory — die TimeVault-Linie, neu geprüft: die Vergangenheit bezeugt, die Zukunft durch ein externes Zeitquorum erzwungen Der Eintrag vom 2026-07-14 schloss mit der These, dass Zeitstempelung die Vergangenheit beweist, die Zukunft aber nicht erzwingt. Seitdem erzwingt die TimeVault-Linie die Zukunft für einzelne Einträge — durch ein externes Zeitquorum, nicht durch Rechenarbeit —, und die Ortsbedingung ist von der Anwendungsrichtlinie in die Schlüsselableitung gewandert. **Methodik.** Problem → Stand der Technik → falsifizierbares Kriterium → Methode → Ergebnis mit Randbedingungen → nächster Schritt. Die Konstruktion beschreiben wir hier nicht. ### 1. Richtung 3, neu geprüft: die Zukunft durch ein externes Zeitquorum erzwingen **Problem.** Ein Eintrag soll bis zu einem gewählten Zeitpunkt unlesbar bleiben — auch für den Eigentümer, den Autor der App und den Betreiber des Dienstes —, gleichgültig, was die Uhr des Geräts anzeigt. **Stand der Technik (veröffentlicht).** Time-Lock-Puzzles (Rivest–Shamir–Wagner, 1996) und VDF (Boneh u. a., 2018) verlangen sequenzielle Arbeit, der Öffnungszeitpunkt hängt also von der Hardware ab; bei Timelock-Verschlüsselung gegenüber einem schwellenbasierten Randomness Beacon (drand, tlock) hängt er an einer Signatur, die der Beacon erst in der jeweiligen Runde veröffentlicht — um den Preis des Vertrauens in den Beacon. **Kriterium (falsifizierbar).** Vor dem gewählten Zeitpunkt öffnet kein einzelner Schlüsselinhaber — weder der Betreiber noch der Autor der App noch der Eigentümer — den Eintrag, und die Uhr des Geräts spielt keine Rolle; danach öffnet er sich mit öffentlich freigegebenen Daten, und eine Hülle aus einer Implementierung des Formats öffnet sich in einer zweiten und umgekehrt. **Methode.** Das öffentliche Hüllenformat `beattime-seal-v1`: ein Quorum aus einem öffentlichen Randomness Beacon, Schlüsselservern von Betreibern und dem Wiederherstellungscode des Eigentümers; der Eintrag bleibt im verschlüsselten Tresor. Die Interoperabilität wird schichtweise und in beide Richtungen geprüft: gegen eine Referenzbibliothek, eine tatsächlich veröffentlichte Beacon-Signatur und eine zweite Implementierung des Formats. **Ergebnis.** Im Rahmen des Kriteriums bestätigt für einzelne Einträge in der mobilen App der Linie, auch zusammen mit der Ortsbedingung; gemessen an der Frage vom Juli ein Teilergebnis: Die vertrauenswürdige Partei wurde durch ein Quorum mit organisatorischer Unabhängigkeit ersetzt. **Grenzen.** - Die Unabhängigkeit der Betreiber ist organisatorisch, nicht kryptographisch: Das Format kann zwei Anteile einer Organisation nicht von Anteilen zweier Organisationen unterscheiden. Derzeit betreibt der öffentliche Zeitdienst des Labors den Schlüsselserver; gegenüber dem Autor der App schützen also der Beacon und der Wiederherstellungscode beim Eigentümer. - Eine Beacon-Kette kann verschwinden; der Wiederherstellungscode gleicht den Verlust eines Beacons aus, nicht den beider. - Der Wiederherstellungscode ist ein statisches Geheimnis: Wer ihn zusammen mit einem vorzeitig freigegebenen Betreiberanteil besitzt — durch Fehler, Zwang oder Absprache —, öffnet den Eintrag früher. - Eine Freigabe zum Termin, die ein Server oder die Gerätesoftware vornimmt, bleibt Richtlinie; das Quorum erfasst nur Einträge in diesem Format. **Nächster Schritt.** Mehr Betreiber — getrennte Organisationen auf getrennter Infrastruktur —, damit vorzeitiges Öffnen die Absprache mehrerer Parteien erfordert. **Status:** implementiert + Interoperabilitätstests; Puzzles und VDF — außerhalb der Implementierung; Erzwingen ohne vertrauenswürdige Parteien — offene Frage. ### 2. Ort: von der Anwendungsrichtlinie zur kryptographischen Bindung **Problem.** Die Bedingung „nur hier öffnen“, von der App nach dem Entschlüsseln geprüft, ist Richtlinie — eine veränderte App oder ein vorgetäuschter Standort umgeht sie. So funktionierte die Ortsbedingung in der TimeVault-Linie vor dem Redesign. **Stand der Technik (veröffentlicht).** Geofencing als Zugriffskontrolle in Anwendungen; Geo-Verschlüsselung, also der Ort als Eingabe der Schlüsselableitung (Scott und Denning, 2003). **Kriterium (falsifizierbar).** Abseits des Ortes existiert kein Schlüssel, es gibt also nichts zu verweigern; die Datei enthält nichts über den Ort — weder Koordinaten noch Radius noch die Angabe, dass überhaupt eine Bindung besteht; der Wiederherstellungscode ersetzt den Ort, nie die übrigen Faktoren. **Ergebnis.** Im Rahmen des Kriteriums bestätigt, für einen Tresor und für einen einzelnen Eintrag; auf dem Gerät verweigerte ein ortsgebundener Eintrag das Öffnen in einer anderen Stadt. Die Konstruktion der Bindung beschreiben wir hier nicht. **Grenzen.** Ein Ort hat wenig Entropie: Die Bindung schützt gegen jemanden, der eine Sicherungskopie besitzt und nicht weiß, wo er stehen müsste, kaum aber gegen jemanden, der das Telefon hat und die Stadt des Eigentümers kennt — ein zusätzlicher Faktor, kein Ersatz für ein starkes Passwort. Ohne Ort und ohne Wiederherstellungscode bleibt der Inhalt endgültig verschlossen. **Nächster Schritt.** Messung des effektiven Suchraums für einen Angreifer, der die Stadt kennt; bislang ist diese Grenze qualitativ beschrieben, nicht gemessen. **Status:** implementiert + Tests, auch auf dem Gerät. ### 3. Negative Ergebnisse und Redesigns seit Juli - **Zugriffsbedingungen im lesbaren Header.** In einer früheren Containerversion standen Ort und Öffnungsdatum im Header — authentifiziert, aber lesbar: Wer die Datei hatte, kannte die Koordinaten, an denen sich der Tresor öffnet. Sie liegen jetzt im verschlüsselten Teil. Lektion: Authentifiziert heißt nicht verborgen. - **Kennungen der Faktordateien (Richtung 2).** Der lesbare Teil der Hülle enthielt Kennungen der Faktordateien in der deklarierten Reihenfolge — entgegen der Anforderung vom Juli und ohne jede Funktion bei der Wiederherstellung: Wer den Container und Kandidatendateien besaß, konnte bestätigen, welche davon Faktoren sind und in welcher Reihenfolge. Das Leck ist beseitigt. **Status:** behoben und durch Tests abgedeckt. ### Korrekturen zum Eintrag vom 2026-07-14 - **Richtung 3, Status „kryptographisches Erzwingen der Zukunft — offene Forschungsfrage“.** Teilweise überholt: Das Erzwingen der Zukunft gibt es für einzelne Einträge (Abschnitt 1). Offen bleibt das Erzwingen ohne vertrauenswürdige Parteien; die These, dass eine Geräterichtlinie Richtlinie bleibt, gilt unverändert. - **Richtung 3, Zeitstempelung („implementiert + Tests“).** Im Webdienst der Linie betraf dieser Status ein eigenes Stempelformat auf Grundlage eines Betreibergeheimnisses; ein solcher Stempel belegt das Vertrauen in den Betreiber, nicht die Zeit, und in diesem Dienst fehlte zudem die externe Verankerung. Das Format ist zurückgezogen; die Stempel dieses Dienstes entstehen jetzt im öffentlichen Zeitdienst des Labors (Eintrag „Zeit als vereinbarte Einheit und als Beweis“) aus einem verblindeten Fingerabdruck der Datei. - **Richtung 2, Anforderung, dass die Hüllen nicht verraten, welche Dateien Faktoren sind.** Zum Zeitpunkt der Veröffentlichung erfüllte die Implementierung sie nicht (Abschnitt 3); behoben. - **Richtung 1 — Präzisierung.** Die Forschungsfrage — dass der Dienst zu keinem Zeitpunkt, auch nicht während der Freigabe, allein etwas entschlüsseln kann — beschreibt das Ziel, nicht eine Eigenschaft der Web-Implementierung: Deren Sicherheitsseite stellt fest, dass der Server bei entsperrter Sitzung Daten im Arbeitsspeicher verarbeitet, und nennt das ein vertrauenswürdiges Sitzungsfenster, nicht „Zero-Knowledge“. Das getestete Kriterium gilt unverändert. **Status der Richtung.** Die Vergangenheit bezeugt ein eigenständiger, öffentlich überprüfbarer Zeitdienst; die Zukunft erzwingt für einzelne Einträge ein Quorum, das Vertrauen verteilt statt beseitigt; die Ortsbindung ist Teil des Schlüssels. Keine der beschriebenen Konstruktionen wurde extern auditiert. --- --- # 🇬🇧 ENGLISH VERSION ## Koch Laboratory — the TimeVault line revisited: the past attested, the future enforced by an external time quorum The entry of 2026-07-14 closed with the thesis that timestamping proves the past but does not enforce the future. Since then the TimeVault line has enforced the future for individual entries — by an external time quorum, not by computation — and the place condition has moved from application policy into key derivation. **Method.** Problem → state of the art → falsifiable criterion → method → result with boundary conditions → next step. The construction is not described here. ### 1. Direction 3 revisited: enforcing the future through an external time quorum **Problem.** An entry must stay unreadable until a chosen moment — to its owner, the author of the application and the operator of the service alike — whatever the device clock shows. **State of the art (published).** Time-lock puzzles (Rivest–Shamir–Wagner, 1996) and VDFs (Boneh et al., 2018) require sequential work, so the moment of opening depends on hardware; with timelock encryption against a threshold randomness beacon (drand, tlock) it depends on a signature the beacon publishes only in the given round — at the price of trusting the beacon. **Criterion (falsifiable).** Before the chosen moment no single key holder — neither the operator, nor the author of the application, nor the owner — opens the entry, and the device clock plays no part; afterwards the entry opens from publicly released data, and an envelope from one implementation of the format opens in a second one, and vice versa. **Method.** The public envelope format `beattime-seal-v1`: a quorum of a public randomness beacon, operators' key servers and the owner's recovery code; the entry stays inside the encrypted vault. Interoperability is checked layer by layer, in both directions: against a reference library, a signature the beacon actually published, and a second implementation of the format. **Result.** Confirmed within the criterion for individual entries in the line's mobile application, also together with the place condition; measured against the July question, partial: the trusted party has been replaced by a quorum whose independence is organisational. **Boundaries.** - Operator independence is organisational, not cryptographic: the format cannot tell two shares held by one organisation from shares held by two. At present the key server is run by the lab's public time service, so against the author of the application the protection is the beacon and the recovery code held by the owner. - A beacon chain can disappear; the recovery code compensates for the loss of one beacon, not of both. - The recovery code is a static secret: whoever holds it together with an operator share released early — by error, coercion or collusion — opens the entry early. - A release on a date carried out by a server or by device software remains policy; the quorum covers only entries in this format. **Next step.** More operators — separate organisations on separate infrastructure — so that opening early requires collusion among more parties. **Status:** implemented + interoperability tests; puzzles and VDFs — outside the implementation; enforcement without trusted parties — open question. ### 2. Place: from application policy to cryptographic binding **Problem.** A condition "open only here", checked by the application after decryption, is policy — a modified build or a spoofed location gets around it. That is how the place condition worked in the TimeVault line before the redesign. **State of the art (published).** Geofencing as access control in applications; geo-encryption, i.e. location as an input to key derivation (Scott and Denning, 2003). **Criterion (falsifiable).** Away from the place the key does not exist, so there is nothing to withhold; the file contains nothing about the place — no coordinates, no radius, not even the fact that a binding is in use; the recovery code stands in for the place, never for the other factors. **Result.** Confirmed within the criterion, for a vault and for a single entry; on a device, a place-bound entry refused to open in another city. The construction of the binding is not described here. **Boundaries.** A place carries little entropy: the binding protects against someone who holds a backup and does not know where to stand, but hardly against someone who has the phone and knows the owner's town — an additional factor, not a substitute for a strong password. Without the place and without the recovery code the content stays closed for good. **Next step.** Measuring the effective search space for an attacker who knows the town; so far this boundary is described qualitatively, not measured. **Status:** implemented + tests, including on a device. ### 3. Negative results and redesigns since July - **Access conditions in the readable header.** In an earlier container version the place and the opening date sat in the header — authenticated but readable: anyone with the file knew the coordinates at which the vault opens. They now sit in the encrypted part. Lesson: authenticated does not mean hidden. - **Identifiers of factor files (direction 2).** The readable part of the envelope contained identifiers of the factor files in their declared order — against the July requirement and with no function in recovery: whoever held the container and candidate files could confirm which of them are factors and in what order. The leak has been removed. **Status:** fixed and covered by tests. ### Corrections to the entry of 2026-07-14 - **Direction 3, status "cryptographic enforcement of the future — open research question".** Partly outdated: enforcement of the future exists for individual entries (section 1). Enforcement without trusted parties remains open; the thesis that device policy remains policy stands unchanged. - **Direction 3, timestamping ("implemented + tests").** In the line's web service this status referred to a stamp format of its own, based on an operator secret; such a stamp evidences trust in the operator, not time, and in that service it also lacked external anchoring. The format has been retired; that service's stamps are now made by the lab's public time service (entry "Time as an agreed unit and as evidence") from a blinded fingerprint of the file. - **Direction 2, the requirement that envelopes must not reveal which files are factors.** At the time of publication the implementation did not meet it (section 3); fixed. - **Direction 1 — clarification.** The research question — that the service be at no point, including during the release, able to decrypt anything on its own — describes the goal, not a property of the web implementation: its security page states that the server processes data in memory while a session is unlocked, and calls this a trusted session window, not "zero-knowledge". The tested criterion stands unchanged. **Status of the direction.** The past is attested by a separate, publicly verifiable time service; the future is enforced for individual entries by a quorum that spreads trust rather than removing it; place binding is part of the key. None of the constructions described has been externally audited.