Koch Laboratory

Zeit als Beweis, neu betrachtet: ein Schlüsselvorfall und ein Log, das sich von außen prüfen lässt

Setzt den Eintrag vom 20. August 2026 fort und korrigiert ihn, jetzt unter dem Namen Sigelith. Ein mit einem Entwicklungsspiegel geteilter Signaturschlüssel widerlegte die Annahme, dass eine gültige Signatur unsere Wurzeln ausweist; das Vertrauen liegt nun bei einem Log, das jeder herunterladen und nachrechnen kann (RFC 9162), und bei Kopien und Ankern in fremder Hand. Dazu Zeitintervalle je Eintrag aus Bitcoin und einer Bank statt aus unserer Uhr, Datensicherungen mit eigenem Nachweis und eine Durchsicht dessen, was ein Client als geprüft anzeigte — jeweils mit ihren Grenzen.

Koch Laboratory — Zeit als Beweis, neu betrachtet: ein Schlüsselvorfall und ein Log, das sich von außen prüfen lässt

Der Eintrag vom 2026-08-20 („Zeit als vereinbarte Einheit und als Beweis”) beschrieb einen Zeitdienst, dessen Angabe für jemanden tragen soll, der weder uns noch unserem Server traut. Sechs Wochen später steht fest, dass eine seiner Aussagen schwächer war, als sie aussah: Mehr als drei Monate lang war derselbe Signaturschlüssel auf zwei Maschinen konfiguriert. Dieser Eintrag beschreibt, was daraus folgte, was als Antwort gebaut wurde und welche Aussagen des vorigen Eintrags einer Korrektur bedürfen. Der vorige Eintrag bleibt unverändert; die Korrekturen stehen hier, mit Datum.

Name. Seit dem 27. September 2026 heißt die gesamte Beweisinfrastruktur — Log, Checkpoints, PDF-Nachweise und Prüf-API — Sigelith und ist unter sigelith.org erreichbar. Seiten unter beattime.live leiten (301) auf dieselbe Adresse unter sigelith.org weiter; die API, die Beweisdateien und alles, was ein Programm liest, antworten unter beiden Adressen ohne Weiterleitung. Die Formatkennungen innerhalb der signierten Bytes bleiben unverändert (beattime-proof-v1, beattime-entry-v1, beattime-checkpoint-v1) — eine Umbenennung in signierten Daten würde jeden bereits ausgestellten Beweis ungültig machen. Der Name BeatTime bezeichnet heute nur noch die beiden Android-Apps: die Uhr und das Zifferblatt für die Smartwatch. Die Uhr bleibt eine Uhr der Internet Time — der Tag in 1000 Teile geteilt, in UTC verankert —, und eine Angabe schreibt man als @beat, etwa @523.

Was hier Forschung ist und was nicht. Die meisten beschriebenen Elemente sind Integration veröffentlichter Standards: Merkle-Bäume mit Inklusions- und Konsistenzbeweisen (RFC 9162), kanonisches JSON (RFC 8785), Ed25519-Signaturen (RFC 8032), OpenTimestamps, authentifizierte Zeitsynchronisation mit NTS (RFC 8915). Keiner dieser Mechanismen stammt von uns. Forschungsgegenstand sind die Grenzen — was genau eine Signatur abdeckt, was ein Anker bezeugt, was eine Kopie nicht bezeugt — und das, was versagt hat.

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 zum Log stammen aus dessen öffentlichen Daten und sind ohne Rückfrage bei uns nachprüfbar; Zahlen aus Tests sind als solche gekennzeichnet.

1. Richtung 1 — negatives Ergebnis: Eine gültige Signatur zeigte nicht, wem eine Wurzel gehört

Problem. Der Eintrag vom 2026-08-20 behandelte die Ed25519-Signatur über der wöchentlichen Merkle-Wurzel als Bestätigung, dass die Wurzel von uns stammt. Vom 15. Juni bis zum 21. September 2026 war derselbe private Schlüssel jedoch auf zwei Maschinen konfiguriert: im Produktivdienst und auf einem Entwicklungsspiegel. Der Spiegel führt dieselben periodischen Aufgaben aus; er schloss daher eigene Wochen ab, signierte deren Wurzeln mit dem gemeinsamen Schlüssel und verankerte sie über OpenTimestamps in Bitcoin. So entstanden zwei solche Wurzeln, für die Wochen 2026-W25 und 2026-W30. Aufgedeckt wurde der Fehler durch eine eigene Sicherheitsüberprüfung im September 2026. Stand der Technik (veröffentlicht). Bei Zeitstempeln nach RFC 3161 und ETSI EN 319 421 wird die Kompromittierung des Schlüssels einer Zeitstempeleinheit durch Widerruf und Benachrichtigung behandelt — das Vertrauen bleibt beim Anbieter. In Certificate Transparency (RFC 6962, RFC 9162) verliert ein Log, das zwei unvereinbare Zustände signiert, das Vertrauen insgesamt. Beide Antworten setzen voraus, dass die Signatur den Aussteller ausweist. Kriterium (falsifizierbar). Hypothese des Eintrags vom 2026-08-20: Eine gültige Signatur mit unserem Schlüssel weist eine Wurzel als unsere aus. Widerlegt wird sie durch eine einzige gültig signierte Wurzel, die nicht unsere ist. Ersatzkriterium: Die maßgebliche Wurzel muss sich ohne Vertrauen in die Signatur bestimmen lassen, aus Daten, die außerhalb unserer Infrastruktur liegen. Methode. Schlüsselrotation am 21. September 2026 und Neusignierung jeder veröffentlichten Wurzel mit dem neuen Schlüssel — die Wurzeln ändern sich nicht, und ihr Bestehen zu einem Zeitpunkt bezeugen Bitcoin und die Bank; die Neusignierung verschiebt also nichts in der Zeit. Den zurückgezogenen Schlüssel lehnt bereits der Signaturcode ab; jede Maschine pinnt den öffentlichen Schlüssel, mit dem sie signieren darf, sodass eine falsch konfigurierte Maschine ohne Signatur endet statt mit einer fremden; der Spiegel verankert nichts mehr. Die Schlüsselhistorie ist öffentlich, und nichts wird aus ihr entfernt. Die erste öffentliche Notiz sprach nur von einer Rotation „nach einer Sicherheitsüberprüfung”; einige Tage später veröffentlichten wir die vollständige Darstellung mit der Liste der verworfenen Wurzeln (sigelith.org/spec/#incident-2026-09), denn eine verworfene Wurzel, die wir nicht selbst benennen, wirkt glaubwürdig auf jeden, dem man sie mit gültiger Signatur vorlegt. Die Seite nennt drei Prüfungen, die ohne Vertrauen in uns durchführbar sind — darunter die für W25 entscheidende: Die Wurzel dieser Woche wurde auf dem Spiegel am Montag derselben Woche eingefroren, und eine Wochenwurzel kann vor dem Ende ihrer Woche nicht endgültig sein. Ergebnis. Hypothese widerlegt: Zwei gültig signierte Wurzeln (2026-W25, 2026-W30) sind nicht unsere; wir veröffentlichen sie selbst, namentlich, als verworfen. Kein Hash im Log hat sich geändert, kein Stempel ging verloren oder wurde rückdatiert — geschwächt ist die Aussage, die allein auf der Signatur beruht. Ersatzkriterium erfüllt: Maßgeblich ist für jede Woche die Wurzel, die sich aus den veröffentlichten Einträgen dieser Woche nachrechnen lässt (Kopien bei Dritten, Richtung 2), und für Wochen mit Bankanker zusätzlich die Wurzel im Verwendungszweck MROOT der Überweisung. Keine der beiden verworfenen Wurzeln besteht diese Prüfung. Das Vertrauen hat sich von der Signatur auf Kopien in fremder Hand und auf die Anker verlagert: Die Signatur ist heute einer der Zeugen, nicht die Identität des Logs. Randbedingungen: Ein OpenTimestamps-Anker bezeugt die Zeit, nicht die Urheberschaft — der Spiegel nutzte dieselben öffentlichen Kalender wie der Produktivdienst; eine Rotation verlangt heute die Änderung der Schlüsselliste an drei Stellen (Dienst, Desktop-Client, öffentliches Log-Repository) und eine neue Client-Version, und ein Client ohne diese Änderung zeigt jeden neuen Beweis als mit fremdem Schlüssel signiert an. Nächster Schritt. Ein einziger Schlüssel signiert heute Wochenwurzeln, Checkpoints und Stempelquittungen. Offene Frage: Sollten Checkpoints Signaturen unabhängiger Zeugen tragen, wie bei einem Teil der Transparenz-Logs, damit der Schlüssel des Betreibers allein — kompromittiert oder falsch konfiguriert — nicht genügt, um eine überzeugende alternative Geschichte vorzulegen? Status: negatives Ergebnis (Hypothese widerlegt); Korrektur umgesetzt und öffentlich beschrieben.

2. Richtung 2 — ein Log, das sich von außen prüfen lässt

Problem. Bis zum 25. September 2026 konnte jeder seinen Eintrag prüfen — den Inklusionspfad zur Wochenwurzel —, aber niemand konnte uns prüfen: das ganze Log herunterladen, von Grund auf nachrechnen und zeigen, dass nichts herausgeschnitten oder umgeschrieben wurde. Nach Richtung 1 ist das keine kosmetische Lücke: Wenn die Signatur nicht genügt, braucht es etwas, das andere aufbewahren. Stand der Technik (veröffentlicht). Certificate Transparency (RFC 6962, RFC 9162): ein Merkle-Baum über das ganze Log, Inklusions- und Konsistenzbeweise, signierte Baumzustände; nach diesem Muster gebaute Transparenz-Logs (u. a. die Prüfsummendatenbank der Go-Module, Sigstore Rekor) sowie Zeugen, die Checkpoints gegenzeichnen. Das Muster ist ausgereift; wir bauen kein neues. Kriterium (falsifizierbar). Eine Person ohne Zugang zu unserer Infrastruktur lädt das ganze Log herunter, rechnet die Hash-Kette und jede Wurzel nach, prüft, dass jeder spätere Checkpoint den früheren erweitert (Konsistenzbeweis nach RFC 9162), und vergleicht die Checkpoints mit Kopien, die andere aufbewahren. Widerlegt wird das Kriterium durch jede Änderung der veröffentlichten Geschichte — ein entfernter, umgeschriebener oder umgestellter Eintrag, zwei verschiedene Checkpoints mit derselben Nummer —, die dieses Verfahren nicht erkennt. Methode. Ein globaler Baum über alle Einträge seit dem ersten, in der Form des Merkle Tree Hash aus RFC 9162. Das Blatt bindet Nummer, Hash und Zeit des Eintrags (beattime-entry-v1|Nummer|Hash|Zeit), sodass ein einziger Pfad belegt: „Dieser Hash war Eintrag Nr. N zum Zeitpunkt T” — und nicht nur: „Dieser Hash steht irgendwo im Baum”. Wochenbäume, ihre Signaturen und die Verwendungszwecke der Überweisungen bleiben unverändert; der globale Baum ergänzt sie, er ersetzt sie nicht. Ein Checkpoint ist ein signierter Baumzustand in kanonischem JSON: täglich und unmittelbar nach Wochenabschluss ausgestellt, über den Hash der vorigen Checkpoint-Datei verkettet, mit einem benannten Bitcoin-Block (Tiefe 3; zwei unabhängige Block-Explorer müssen übereinstimmen) und selbst über OpenTimestamps in Bitcoin verankert. Checkpoint Nr. 1 (25. September) umfasst das ganze Log seit dem ersten Eintrag — 171 Einträge. Das ganze Log lässt sich herunterladen (Eintragsseiten und wöchentliche Exportdateien), Konsistenzbeweise zwischen Checkpoints sind öffentlich abrufbar (sigelith.org/checkpoints/). Kopien bei Dritten entstehen automatisch: OpenTimestamps/Bitcoin — jeder Checkpoint, täglich; Verwendungszweck MROOT einer Banküberweisung — jede Wochenwurzel, wöchentlich; GitHub (unveränderliche Releases, github.com/DeiFlagellum/sigelith-log) und Internet Archive — wöchentlich; Zenodo — vierteljährlich, ein vollständiger Schnappschuss unter CC0. Seit dem 28. September trägt jede Antwort auf eine Stempelung eine signierte Quittung (Nummer, Hash, Zeit, Kettenglied): Ein Log, dem ein solcher Eintrag später fehlt, wird durch die eigene Signatur überführt — dieselbe Rolle spielen SCTs in Certificate Transparency. Der Desktop-Client (heute Sigelith Desktop, vor Version 3.0 BeatStamp) prüft seit Version 2.2 im Hintergrund jeden Checkpoint — Dateibytes, Signatur, Kette, Konsistenz —, vergleicht ihn Byte für Byte mit den Kopien bei GitHub, Internet Archive und Zenodo und prüft den Block bei einem unabhängigen Explorer; einen Checkpoint mit bekannter Nummer und anderem Inhalt bewahrt er als Beweismaterial auf. Im Standardmodus hält er eine Kopie des ganzen Logs und berechnet die Pfade selbst; der Server erfährt höchstens, nach welcher Woche gefragt wurde. Ergebnis. Im Rahmen des Kriteriums bestätigt. Inklusions- und Konsistenzbeweise wurden vor der Inbetriebnahme für jede Baumgröße von 1 bis 64 erschöpfend geprüft (Test): 2080 von 2080 echten Beweisen jeder Art angenommen, 8190 von 8190 Fälschungen verworfen (u. a. falscher Pfad, falscher Index, umgeschriebener Eintrag in der Geschichte); die Erzeugung folgt der rekursiven Definition, die Prüfung dem iterativen Algorithmus — beide Formen aus RFC 9162 müssen dasselbe ergeben. Eine zweite Implementierung, allein aus dem Text der Spezifikation geschrieben und bewusst ohne Import von Produktivcode, reproduzierte den Produktivdienst beim ersten Lauf am 25. September: 171 Einträge, 13 wöchentliche Exportdateien, globale Wurzel und Wochenwurzeln übereinstimmend, Wochenwurzeln gleich den Verwendungszwecken MROOT. Zum Zeitpunkt des Schreibens wurde dies mit einer weiteren, separat geschriebenen Implementierung wiederholt: Die Wurzeln bei 171 und 211 Einträgen entsprechen den Wurzeln der Checkpoints Nr. 1 und Nr. 8, der Konsistenzbeweis zwischen ihnen ist gültig, ebenso die Signatur von Checkpoint Nr. 1. Randbedingungen: (a) Ein erschöpfender Test an kleinen Bäumen spricht für die Korrektheit der Implementierung, beweist sie aber nicht; (b) die zweite Implementierung ist im Code unabhängig, nicht in der Person — sie stammt vom selben Autor; ein Audit durch Dritte gab es bisher nicht; (c) die Kopien bei GitHub, Internet Archive und Zenodo sind passiv — sie bewahren auf, prüfen aber vor der Annahme nichts; geprüft wird von Clients und von jedem, der sie herunterlädt, und gegenzeichnende Zeugen gibt es nicht; (d) die Geschichte vor dem 25. September wird als Ganzes erst durch Checkpoint Nr. 1 festgehalten, davor nur durch die wöchentlichen Anker; (e) der Servercode ist nicht öffentlich und muss es nicht sein, weil die Prüfung ihn nicht nutzt: Die Formate beschreiben die Spezifikation und das öffentliche Log-Repository; (f) lokal prüft der Desktop-Client; Browserseiten und die Android-App berechnen den Hash einer Datei lokal, übernehmen den Log-Teil aber aus der Serverantwort und verweisen auf die unabhängigen Kopien zum eigenen Vergleich. Nächster Schritt. Ein eigenständiges Prüfskript für Dritte, das den Checkpoint aus einer unabhängigen Kopie bezieht und nicht von uns — der einzige noch offene Punkt des Plans dieser Richtung. Status: umgesetzt seit dem 25. September 2026 (erstes Wochen-Release: 2026-W39, erste Quartalsversion: 2026-Q3).

3. Richtung 3 — ein Zeitintervall für jeden Eintrag aus externen Ankern statt aus unserer Uhr

Problem. Die Zeit eines Eintrags ist die Angabe unserer Serveruhr. Der Eintrag vom 2026-08-20 stützte sich auf die Wochengranularität („nicht später als”) und auf die Veröffentlichung des eigenen Uhrenfehlers, doch beides bleibt unser Wort. Der schwerste Vorwurf gegen jeden Zeitstempeldienst lautet: Der Betreiber hat einen Eintrag auf Wunsch rückdatiert. Die Antwort darauf darf nicht von der Uhr des Betreibers abhängen. Stand der Technik (veröffentlicht). RFC 3161: Die Zeit stammt von der Uhr der Stelle und ist so viel wert wie das Vertrauen in sie; verkettete Zeitstempel (Haber und Stornetta, 1991) — Reihenfolge ohne Vertrauen, aber ohne absolute Zeit; OpenTimestamps — eine Obergrenze („existierte nicht später als”) aus Bitcoin; Roughtime — authentifizierte Grobzeit mit Beweis für Fehlverhalten des Servers; NTS (RFC 8915) — authentifizierte Uhrensynchronisation. Die Untergrenze liefert eine bekannte Technik: Ein Wert, der vor einem bestimmten Zeitpunkt nicht bekannt sein konnte — hier der Hash eines Bitcoin-Blocks —, belegt, dass alles, was ihn enthält, später entstanden ist. Kriterium (falsifizierbar). Für jeden Eintrag lassen sich beide Grenzen ohne unsere Uhr ableiten, aus Daten außerhalb unserer Infrastruktur, und die erfasste Zeit des Eintrags liegt dazwischen. Widerlegt wird das Kriterium durch einen einzigen Eintrag, dessen erfasste Zeit außerhalb seines eigenen Intervalls liegt. Methode. Jeder Eintrag hat drei Zeiten. Erfasst — die Serveruhr, auf die Mikrosekunde; das ist unser einziges Wort. Nicht früher als — der Bitcoin-Block, der im letzten vor dem Eintrag ausgestellten Checkpoint genannt ist: Der Eintrag liegt außerhalb des Baums dieses Checkpoints, wurde also später angefügt, und der Checkpoint konnte nicht vor dem Schürfen seines Blocks entstehen. Nicht später als — der früheste Anker, der den Eintrag abdeckt: die OpenTimestamps-Attestierung des ersten Checkpoints, der ihn enthält, die Attestierung der Wochenwurzel oder die Buchung der Überweisung mit dieser Wurzel. API und PDF-Nachweis nennen alle drei, zusammen mit dem Pfad des Eintrags zum ersten Checkpoint, der ihn enthält — der Nachweis und ein Checkpoint aus einer unabhängigen Kopie genügen zur Prüfung ohne uns. Unabhängig davon folgt die Uhr des Hosts heute vier Zeitservern dreier unabhängiger Betreiber, authentifiziert über NTS; eine Quelle, die von den übrigen abweicht, wird überstimmt. Der Dienst misst außerdem alle fünf Minuten seinen Offset gegenüber einem externen Server und veröffentlicht das Ergebnis — das Intervall aus den Ankern braucht diese Messung jedoch nicht. Ergebnis. Bestätigt für Einträge seit dem ersten Checkpoint (25. September 2026); teilweise für das Log als Ganzes. Eine Prüfung zum Zeitpunkt des Schreibens umfasste alle 41 Einträge seit diesem Zeitpunkt: Die erfasste Zeit liegt in jedem Fall im Intervall; 40 Einträge haben beide Grenzen (der neueste wartet auf den Anker des nächsten Checkpoints); die Intervallbreite reicht von etwa 14 bis 25,5 Stunden, der Median liegt bei etwa 25. Beispiel: Eintrag Nr. 191 (Bekanntgabe des Namens Sigelith), erfasst am 27. September um 17:17:27 UTC — nicht früher als 26. September, 23:43 UTC (Block 968756), nicht später als 28. September, 00:35 UTC (Block 968908). Randbedingungen: (a) Blockzeiten stammen aus den Block-Headern, die der Miner mit einer Genauigkeit von etwa zwei Stunden setzt — die Grenzen sind auf Stunden genau, nicht auf Sekunden; (b) das Intervall betrifft den Zeitpunkt der Erfassung im Log, nicht die Entstehung des Dokuments; (c) die 171 Einträge vor dem ersten Checkpoint haben nur eine Obergrenze, und eine Untergrenze lässt sich nicht nachträglich hinzufügen; (d) die Bankbuchung trägt ein Datum ohne Uhrzeit; (e) die Untergrenze beruht auf der unveränderlichen Reihenfolge des Logs, und diese prüfen die Konsistenzbeweise gegen Kopien bei anderen (Richtung 2). Nächster Schritt. Der Bankanker ist heute öffentlich als Verwendungszweck MROOT und als Referenznummer sichtbar; eine eigenständige Prüfung verlangt einen Kontoauszug oder eine Bestätigung der Bank. Die Spezifikation lässt die Veröffentlichung geschwärzter Auszüge zu, bisher wurde keiner veröffentlicht. Nächster Schritt: klären, ob ein solcher Auszug einem Dritten etwas gibt, was die Referenznummer allein nicht gibt. Status: umgesetzt; volles Intervall für Einträge seit dem 25. September 2026, für frühere nur die Obergrenze.

4. Richtung 4 — eine Datensicherung, die ihren eigenen Nachweis mitführt

Problem. Ein Sicherungsprogramm vergleicht Dateien mit seinem eigenen Inhaltsverzeichnis, das neben ihnen liegt. Wer Dateien austauscht — Ransomware, ein Einbruch, ein alternder Datenträger, jemand mit Zugriff auf das Laufwerk —, kann auch das Verzeichnis austauschen, und die Prüfung fällt dann positiv aus. Zudem verlangt der Nachweis, dass eine bestimmte Datei in der Sicherung eines bestimmten Tages enthalten war, meist die Offenlegung der ganzen Sicherung oder zumindest ihres Verzeichnisses. Stand der Technik (veröffentlicht). restic (check --read-data) und Borg (check --verify-data) prüfen die Daten gegen den authentifizierten Index des Repositorys — der Schutz beruht auf einem Schlüssel, den der Nutzer verwahrt; unveränderliche Datenträger und Speicher (WORM, Object Lock) schützen vor Änderungen, liefern Dritten aber für sich keinen Nachweis; gesalzene Hashes zur selektiven Offenlegung (u. a. SD-JWT); Domänentrennung von Blättern und Knoten nach RFC 6962. Kriterium (falsifizierbar). (1) Ein Eintrag im öffentlichen Log je Sicherungsversion, ohne Dateinamen und deren Hashes; (2) für jede einzelne Datei ein Nachweis, der keine anderen Dateien der Version offenlegt; (3) eine Prüfung, die den Austausch einer Datei auch dann erkennt, wenn das Verzeichnis neben den Dateien ausgetauscht wurde. Widerlegt wird das Kriterium durch einen Austausch, den die Prüfung bei unverändertem Log-Eintrag nicht erkennt. Methode. Sigelith Backup — ein Programm für versionierte, optional verschlüsselte Sicherungen auf ein externes Laufwerk, mit öffentlichem Code (github.com/DeiFlagellum/sigelith-backup) — versieht jede Version mit einer Erklärung: dem Hash des Versionsverzeichnisses (Pfad, Größe und SHA-256 jeder Datei) und der Wurzel eines Merkle-Baums über den Dateien der Version. Ein Blatt ist der SHA-256 über Domänenbyte, Salz, Datei-Hash, Größe und Pfad-Hash; das Salz ist ein HMAC-SHA256 aus einem zufälligen Startwert der Version und dem Pfad. In das Log gelangt nur der Hash der Erklärung — ein Eintrag je Version. Der Nachweis einer einzelnen Datei (sigelith-file-proof-v1) besteht aus dem Pfad im Baum, der Erklärung und dem eingebetteten Nachweis des Log-Eintrags; den Dateipfad kann er offenlegen oder nicht. Die Prüfung kontrolliert die Erklärung ohne Netz (Pfad im Wochenbaum und Signatur mit einem im Programm hinterlegten, nicht vom Server gelieferten Schlüssel) und liest dann jede Datei vom Datenträger — nach Entschlüsselung mit Prüfung des GCM-Authentifizierungs-Tags und nach dem Zusammensetzen der Fragmente — und vergleicht sie mit dem Hash aus der Erklärung. Maßstab ist der Eintrag im öffentlichen Log, nicht das Verzeichnis neben den Dateien. „Letzte unberührte” ist die neueste Version, die zu ihrem Eintrag passt — aus ihr sollte man nach einem Angriff wiederherstellen. Die laufende Sicherung ergänzt Änderungen in der heutigen Version; eine Version, die bereits ihre Erklärung erhalten hat, wird nie ergänzt, und bei eingeschalteter Stempelung schließt die erste Ergänzung eines neuen Tages die gestrige Version ab und stempelt sie erst dann. Ergebnis. Im Rahmen des Kriteriums bestätigt (Tests): Der Austausch einer Datei wird auch nach Zerstörung oder „Korrektur” des Inhaltsverzeichnisses erkannt; ein geändertes Verzeichnis, das von der Erklärung erfasst ist, ergibt kein falsches „unberührt”; in einer verschlüsselten Sicherung wird ein einzelnes geändertes Bit des Chiffrats erkannt; der Pfad zur Wurzel wurde für Bäume mit 1 bis 1000 Blättern geprüft; der Dateinachweis legt weder andere Dateien noch den Startwert offen. Dasselbe Nachweisformat prüfen drei Implementierungen an einem gemeinsamen Testvektor: das Programm selbst, der Desktop-Client und die Prüfseite im Browser. Randbedingungen, ausdrücklich: (a) Die Prüfung bindet die Dateien an irgendeinen Eintrag im öffentlichen Log, belegt aber nicht, dass es der erste Eintrag für diese Version ist — stempeln kann jeder, also kann, wer Schreibzugriff auf den Datenträger hat, eine Version neu aufbauen und mit einem neuen Eintrag versehen; verraten würde ihn das spätere Datum des Eintrags — das Programm zeigt es in seiner Zeitstempel-Ansicht an, die Prüfung vergleicht es heute aber nicht mit dem Datum der Version; (b) fehlendes Netz ist kein Sicherungsfehler — der Eintrag wird mit der nächsten Sicherung gesendet, sodass auch ein redlicher Eintrag später als das Versionsdatum liegen kann, was die Unterscheidung aus (a) schwächt; (c) bei eingeschalteter Stempelung liegen auf einem verschlüsselten Datenträger das Versionsverzeichnis (Pfade, Größen und SHA-256 des Klartexts jeder Datei) und die Erklärung unverschlüsselt neben den verschlüsselten Dateien — die Pfade sind ohnehin als Dateinamen sichtbar, die Klartext-Hashes erlauben aber jedem, der den Datenträger hat, zu prüfen, ob eine ihm bekannte Datei in der Sicherung liegt; (d) der Dateinachweis bezeugt, dass eine Datei mit genau diesen Bytes Teil einer zu einem bestimmten Zeitpunkt gestempelten Version war — nicht, wann die Datei entstand oder wer sie verfasst hat; (e) die laufende Sicherung hat einen Nachweis mit Tagesgenauigkeit: Änderungen des laufenden Tages haben keinen Eintrag, bis die Version dieses Tages abgeschlossen ist. Nächster Schritt. Zwei offene Entscheidungen: ob die Prüfung das Datum des Eintrags selbst mit dem Datum der Version vergleichen soll — und wie sich eine verspätete Stempelung von einer neu aufgebauten Version unterscheiden lässt —, und ob das Versionsverzeichnis einer verschlüsselten Sicherung verschlüsselt werden soll: Der Preis ist die Prüfung der Erklärung ohne Passwort, der Gewinn ein Datenträger, der keine Klartext-Hashes preisgibt. Status: umgesetzt (Sigelith Backup 3.0, öffentlicher Code); die Grenzen (a)–(e) gelten.

5. Richtung 5 — Durchsicht des Clients: was er als geprüft anzeigte und was er nicht prüfte

Problem. Ein Prüfprogramm, das als geprüft anzeigt, was es nicht geprüft hat, ist schlechter als keines: Es verwandelt die Behauptung des Ausstellers in ein grünes Häkchen beim Empfänger. Der Desktop-Client ist der Ort, an dem Beweise ohne Rückfrage beim Server geprüft werden — also der erste, der daraufhin durchgesehen werden musste. Stand der Technik (veröffentlicht). Eine bekannte Fehlerklasse: Die Oberfläche schreibt die Gültigkeit einer Signatur Daten zu, die die Signatur nicht abdeckt — beschrieben u. a. für E-Mail-Clients mit OpenPGP und S/MIME („Johnny, you are fired!”, USENIX Security 2019) und für PDF-Signaturen; das Pinnen eines einzigen Schlüssels ohne Historie — derselbe Ausfallmechanismus, wegen dessen die Browser HTTP Public Key Pinning (RFC 7469) zurückgezogen haben. Kriterium (falsifizierbar). Jeder als geprüft angezeigte Wert ist durch eine Kontrolle gedeckt, die der Client tatsächlich ausgeführt hat; jeder andere ist als Angabe gekennzeichnet. Widerlegt wird das Kriterium durch einen einzigen als geprüft angezeigten Wert ohne diese Deckung. Methode. Durchsicht des Client-Codes gegen die Formatspezifikation — was genau jede Signatur und jeder Pfad abdeckt — und Tests mit Manipulationsfällen. Ergebnis. Kriterium widerlegt für die Versionen vor 2.1. Gefundene Fehlerklassen, alle in Version 2.1 (September 2026) behoben: (1) Der Client hatte einen einzigen Schlüssel fest hinterlegt — den zurückgezogenen; nach der Rotation hätte er jeden aktuellen Beweis als mit fremdem Schlüssel signiert verworfen und zugleich die Wurzeln des Spiegels angenommen; heute ergibt sich das Vertrauen aus einer eingebauten Schlüsselhistorie mit Daten, und eine Signatur mit einem zurückgezogenen Schlüssel ergibt höchstens die Stufe „registriert” mit der Bitte um Aktualisierung; (2) eine Beweisdatei mit verschobenem Datum wurde als „offline verifiziert” angenommen — die Signatur deckt Woche und Wurzel ab, das Blatt des Wochenbaums nur den Hash, die genaue Zeit in der Datei war also eine unsignierte Angabe; heute muss sie in der signierten Woche liegen, und strukturell schließt die Lücke das Blatt des globalen Baums, das die Zeit bindet (Richtung 2); (3) der PDF-Bericht nannte einen verworfenen Beweis bestätigt; (4) Bankanker wurden gezählt, ohne zu prüfen, ob sie dieselbe Wurzel tragen; (5) einige Felder aus der Serverantwort gelangten ohne Maskierung von Sonderzeichen in Beschriftungen der Oberfläche. Randbedingungen: Die Durchsicht war intern, kein externes Audit; sie betrifft den Desktop-Client (github.com/DeiFlagellum/sigelith-desktop) — den einzigen, der den Log-Teil lokal prüft. Nächster Schritt. Die Manipulationsfälle aus dieser Durchsicht in die gemeinsamen Testvektoren aufnehmen, damit jedes Prüfprogramm — im Sicherungsprogramm, im Desktop-Client und im Browser — am selben Satz geprüft wird. Status: Korrekturen umgesetzt; interne Durchsicht.

Korrekturen zum Eintrag vom 2026-08-20

Der Eintrag vom 2026-08-20 bleibt unverändert. Im Folgenden seine Aussagen, die veraltet sind oder nicht genau waren.

Der Stempel des Eintrags selbst. Der Eintrag vom 2026-08-20 wurde am 20. August 2026 um 14:52 UTC gestempelt, in der Woche 2026-W34 — im Zeitraum des Vorfalls aus Richtung 1. Die Wurzel dieser Woche hatte ursprünglich der zurückgezogene Schlüssel signiert; heute trägt sie eine Signatur des neuen Schlüssels. Das Datum des Eintrags beruht nicht auf jener Signatur, sondern auf den Ankern: der Buchung der Überweisung mit der Wurzel der Woche W34 (25. August) und der Bitcoin-Attestierung dieser Wurzel über OpenTimestamps (26. August); auch Checkpoint Nr. 1 umfasst ihn. Eine Untergrenze aus Ankern gibt es nicht — der Eintrag ist älter als der erste Checkpoint. Die neben jenem Eintrag veröffentlichte Stempeldatei hält den Stand zum Zeitpunkt der Stempelung fest (Woche offen, vorläufige Wurzel); die endgültige Wurzel, den Pfad zu ihr und die Anker liefert das Log, etwa die Exportdatei der Woche 2026-W34 in der Quartalskopie bei Zenodo.

„Die Anwendungsschichten (Android, Wear, Erweiterung, SDK) befinden sich im Aufbau”. Veraltet: Die Android-App und das Zifferblatt für die Smartwatch, der Desktop-Client, die Browsererweiterung und die SDK-Pakete sind veröffentlicht.

Richtung 2: „eine periodische Aufgabe misst die Abweichung der Hostuhr gegenüber NTP”. Ungenau. Die Messung ist eine einzelne, nicht authentifizierte SNTP-Abfrage an einen einzigen externen Server; das Ergebnis ist die Differenz zu diesem Server, kein Fehler gegenüber UTC, und bleibt unsere Angabe — ein Zustandssignal des Dienstes, kein Beweis. Die Hostuhr folgt heute vier über NTS authentifizierten Servern, und der Zeitbeweis stützt sich nicht auf unsere Uhr (Richtung 3).

Richtung 3: die Ed25519-Signatur als Teil des Ergebnisses „bestätigt”. Für den Zeitraum vom 15. Juni bis zum 21. September 2026 ungenau: Derselbe private Schlüssel lag auf dem Entwicklungsspiegel, eine gültige Signatur wies eine Wurzel also nicht als unsere aus (Richtung 1). Zudem war das Log Eintrag für Eintrag prüfbar, nicht aber als Ganzes — diese Lücke schließt Richtung 2.

Richtung 4: „mindestens zwei unabhängige Ankerkanäle … jeder für sich prüfbar” — bestätigt. Präzisierungsbedürftig. (a) Ein Anker bezeugt die Zeit, nicht die Urheberschaft: Der Entwicklungsspiegel verankerte seine Wurzeln über dieselben öffentlichen OpenTimestamps-Kalender. (b) Der Bankkanal ist in der Erfassung von uns unabhängig, doch ein Dritter sieht öffentlich nur den Verwendungszweck MROOT und die Referenznummer; eine eigenständige Prüfung verlangt einen Kontoauszug oder eine Bestätigung der Bank. (c) Für die Wochen 2026-W32, W33 und W34 kam die Bitcoin-Attestierung der Wurzeln erst am 26. August — 16,5, 9,5 und 2,5 Tage nach Wochenabschluss; die Obergrenze für diese Wochen bestimmt die Bankbuchung, am Tag des Abschlusses oder einen Tag danach. Der zweite Kanal erwies sich als nicht überflüssig. (d) Der manuelle Schritt des Bankkanals versagte einmal: Für 2026-W30 wurde ein zweiter Datensatz derselben Referenz mit einem Wert erfasst, der nicht die Wochenwurzel ist. Der Datensatz bleibt sichtbar und ist als nicht übereinstimmend gekennzeichnet; das Formular trägt die Wurzel heute selbst ein und prüft ihre Übereinstimmung mit der Woche.

Richtung 6: Ko-Stempel-Protokoll v2. Eine Replay-Lücke: Die Startsignatur der ersten Seite war nicht an eine einzelne Sitzung gebunden, sodass die öffentlichen Daten einer abgeschlossenen Sitzung genügten, um in ihrem Namen eine neue zu eröffnen; das Log konnte dann einen Ko-Stempel enthalten, den der Inhaber dieses Schlüssels nie ausgeführt hat. Seit dem 21. September wird ein Salz aus einer abgeschlossenen Sitzung abgelehnt.

„Nächster Forschungsschritt: … (C2PA)”. Nicht aufgenommen; die Arbeit an C2PA hat nicht begonnen. Umgesetzt wurde ein anderer Schritt: ein Log, das sich von außen prüfen lässt (Richtung 2).

Status der Richtung. Die Beweisinfrastruktur läuft unter dem Namen Sigelith. Der Schlüsselvorfall hat die Annahme widerlegt, dass die Signatur unsere Wurzeln ausweist; das Vertrauen stützt sich heute auf ein Log, das jeder herunterladen und nachrechnen kann, auf Kopien bei GitHub, Internet Archive und Zenodo sowie auf Anker in Bitcoin und bei einer Bank. Jeder Eintrag seit dem 25. September 2026 hat ein von unserer Uhr unabhängiges Zeitintervall; Sicherungen führen ihren eigenen Nachweis mit offen benannten Grenzen; der Desktop-Client zeigt als geprüft nur, was er geprüft hat. Nächste Schritte: ein eigenständiges Prüfskript für Dritte und die Entscheidungen aus Richtung 4. Zeitkapseln — bis zu einem gewählten Zeitpunkt verschlossene Umschläge — und das Protokoll für Zustellnachweise werden in einem eigenen Eintrag beschrieben.

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.

· @529.58 · 2026-W40

SHA-256 des gestempelten Textes: 90ee5eb66f12eaaa998a1eca1e9f5688ce04a7e322e5398c397ca7ac4882adc2

Prüfen mit: ots verify <Nachweis> --file <Quelle>