Die TimeVault-Linie, neu geprüft: die Vergangenheit bezeugt, die Zukunft durch ein externes Zeitquorum erzwungen
Setzt den Eintrag vom 2026-07-14 fort: Das Erzwingen der Zukunft gibt es jetzt für einzelne Einträge — durch ein externes Zeitquorum statt eines Time-Lock-Puzzles, mit offen benannten Vertrauensgrenzen —, die Ortsbedingung ist von der Anwendungsrichtlinie in den Schlüssel gewandert, und die negativen Ergebnisse seit Juli erscheinen zusammen mit Korrekturen überholter Aussagen des Juli-Eintrags.
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.
Zeitnachweis
Dieser Text wurde bei der Veröffentlichung gehasht und gestempelt. Zur Prüfung sind beide Dateien nötig: der Stempel belegt, dass genau eine Bytefolge zu diesem Zeitpunkt existierte, und nur die Quelle unten ist diese Bytefolge. Jede spätere Änderung verschiebt den Hash und bricht die Übereinstimmung — genau das ist der Zweck.
SHA-256 des gestempelten Textes: 0423ffe937b37667786bee63fc0abdd635e41e38bf3e3ef523c41e16a85cab7d
- Sigelith-Anker portfolio-timevault-capsules.public.md.beattime.json
- OpenTimestamps-Nachweis portfolio-timevault-capsules.public.md.ots
- Gestempelter Quelltext portfolio-timevault-capsules.public.md
Prüfen mit: ots verify <Nachweis> --file <Quelle>