Wie du einen versiegelten Eintrag empfängst

Um einen versiegelten Eintrag zu empfangen, teilst du eine Empfangsadresse und lässt deine Software die Einträge finden, die deine Schlüssel öffnen können. Es gibt keinen Posteingang, den der Server für dich füllt. Dein Client durchsucht den öffentlichen Label 309-Feed, probiert deine Empfangsschlüssel an jedem versiegelten Eintrag aus und zeigt die an, die sich erfolgreich entschlüsseln lassen.

Genau diese Umkehrung ist die ganze Idee: Deine Inbox wird durch Entschlüsselung entdeckt, nicht von einem Server zugewiesen. Die Chain trägt nie ein lesbares Empfängerfeld, und das Gateway muss nie wissen, welche Einträge dir gehören.

Was ist ein versiegelter Eintrag?

Ein versiegelter Eintrag ist ein Existenznachweis mit verschlüsseltem Inhalt.

Der öffentliche Eintrag legt sich weiterhin auf den Klartext-Hash fest, sodass der Nachweis später zeigen kann, dass genau dieser Inhalt zu einer öffentlichen Blockzeit existierte. Die Datei selbst ist verschlüsselt, und der Chiffretext liegt an einem inhaltsadressierten Speicherort wie Arweave oder IPFS – nie auf der Chain. (Zur Mechanik des öffentlichen Nachweises siehe wie Label 309 funktioniert.)

Wer einen passenden Schlüssel besitzt, kann den Chiffretext entschlüsseln, die ursprünglichen Bytes wiederherstellen, den Klartext-Hash neu berechnen und bestätigen, dass die entschlüsselte Datei zum On-Chain-Commitment passt. Wer keinen Schlüssel hat, sieht, dass ein versiegelter Eintrag existiert – sollte aber den Inhalt nicht lesen können.

Was gebe ich dem Absender?

Du gibst dem Absender eine Empfangsadresse. Mehr nicht.

Für versiegelte Label-309-Einträge gibt es Empfangsadressen in zwei Formen:

• age1… – der klassische X25519-Empfangspfad.
• age1pqc1… – ein hybrider Post-Quanten-Empfangspfad (X25519 kombiniert mit ML-KEM-768, in der X-Wing-Konstruktion).

Eine Empfangsadresse ist öffentlich und gefahrlos teilbar. Sie erlaubt jemandem nur, einen Eintrag an dich zu verschlüsseln, und sonst nichts. Sie wird aus deiner Identität abgeleitet, gibt diese aber nicht preis.

Gib dem Absender nicht deinen Identity Seed. Der Seed ist die private Wurzel deiner Identität – die 32 Bytes, aus denen sich dein Signaturschlüssel und deine Empfangsschlüssel deterministisch ableiten. Wer ihn besitzt, kann als du signieren und entschlüsseln. (Mehr dazu, warum der Seed das eigentliche Backup ist: deine Identität ist ein Seed.)

Wie erstellt der Absender den Eintrag?

Die Software des Absenders versiegelt lokal. Im Überblick:

1. Der Absender wählt eine Datei oder eine Nachricht.
2. Die Software berechnet den Klartext-Hash.
3. Die Software erzeugt einen einmaligen Inhaltsschlüssel und verschlüsselt den Inhalt.
4. Für jeden Empfänger umhüllt sie diesen Inhaltsschlüssel mit dem Empfangsschlüssel des Empfängers und erzeugt so einen empfängerspezifischen Slot.
5. Der Chiffretext wird in einen inhaltsadressierten Speicher hochgeladen (etwa ar://).
6. Ein Label-309-Eintrag wird auf Cardano veröffentlicht und trägt den Klartext-Hash und den versiegelten Umschlag.

Der On-Chain-Eintrag beweist den Zeitpunkt und trägt die umhüllten Schlüssel-Slots. Der gespeicherte Chiffretext enthält die verschlüsselte Datei. Dein privater Schlüssel öffnet deinen Slot. Dieselbe Abfolge – hashen, signieren, versiegeln, teilen – wird in hashen, signieren, versiegeln, teilen Schritt für Schritt durchgegangen.

Wie findet mein Client einen Eintrag, der für mich bestimmt ist?

Dein Client durchsucht öffentliche Einträge und versucht, sie zu öffnen.

Das ist der Teil, der ungewohnt wirkt, wenn du einen normalen Posteingang erwartest. In einer gehosteten Inbox weiß der Server, zu welchem Konto eine Nachricht gehört, und leitet sie weiter. Ein versiegelter Label-309-Eintrag trägt kein solches Routing. Der Umschlag listet umhüllte Schlüssel-Slots auf, aber nirgendwo auf der Leitung erscheint ein öffentlicher Empfängerschlüssel – es gibt kein Adressatenfeld zum Auslesen.

Also synchronisiert dein Client den öffentlichen Feed der Label-309-Einträge und prüft bei jedem versiegelten Eintrag, ob sich ein Slot mit den Empfangsschlüsseln deiner Identität öffnen lässt. Das ist lokale Probeentschlüsselung: der Versuch, jeden Slot zu entpacken, vollständig auf deinem Gerät ausgeführt. Öffnet sich ein Slot, gehört der Eintrag dir und dein Client fügt ihn deiner Inbox hinzu. Öffnet sich keiner, ignoriert dein Client ihn.

Eine feine, aber wichtige Folge: Auch die Reihenfolge der Slots verrät nichts. Ein Absender mischt die Slots vor dem Veröffentlichen, sodass selbst die Position des „primären Empfängers“ kein Signal trägt.

Muss die Probeentschlüsselung jede Datei herunterladen?

Nein. Die Probeentschlüsselung läuft gegen den Umschlag, der im On-Chain-Eintrag steckt, nicht gegen die gespeicherte Datei.

Die umhüllten Slots und ein kleiner Authentifizierungs-Tag liegen in den Metadaten des Eintrags selbst. Dein Client kann allein aus diesen On-Chain-Bytes feststellen, dass ein Eintrag an dich adressiert ist – und den Inhaltsschlüssel wiederherstellen –, bevor er irgendeinen Chiffretext abruft. Das ist entscheidend, weil Chiffretext groß sein kann: Ein Desktop-Client kann zuerst herausfinden, welche Einträge dir gehören, und die verschlüsselten Dateien dann verzögert abrufen, wenn du sie öffnest, oder sie gemäß deinen Einstellungen vorab cachen.

Für einen Offline-First-Client ist diese Aufteilung das Fundament:

• den öffentlichen Eintrags-Feed synchronisieren;
• lokal gegen die Umschläge probeentschlüsseln;
• den passenden Chiffretext cachen, wenn du ihn willst;
• bei Bedarf entschlüsseln, wenn du eine Datei öffnest;
• alles bereits Synchronisierte ohne Netzwerk nutzbar halten.

Was weiß das Gateway eigentlich?

Ein Gateway weiß, was jeder öffentliche Beobachter weiß, plus die betrieblichen Details des Dienstes, den es betreibt.

Bei einem gehosteten Gateway kann das die Kontoaktivität umfassen, die API-Nutzung, deinen Quote-und-Publish-Ablauf, die Upload-Aktivität, den Guthabenstand, Infrastrukturdaten auf Netzwerkebene und die öffentlichen Eintrags-Metadaten, die jeder sehen kann. (Zum vollständigen Bild der Grenze siehe was CardanoWall sehen kann.)

Was es nicht braucht, sind dein Identity Seed, deine privaten Empfangsschlüssel oder irgendeine Fähigkeit, versiegelten Inhalt für dich zu entschlüsseln. Die Privatsphäre-Eigenschaft hier ist nicht „der Server erfährt nichts über irgendetwas“ – das wäre unehrlich. Sie ist enger und nützlicher: Empfängerabgleich und Entschlüsselung passieren lokal, sodass kein lesbares Empfängerfeld veröffentlicht und nie ein privater Schlüssel an das Gateway gesendet wird. Das Gateway ist von Grund auf empfängerblind; jeder Versuch, Einträge nach Empfänger zu filtern, wird schlicht ignoriert, weil es keine Empfängerspalte gibt, nach der sich filtern ließe.

Warum gibt es kein öffentliches Empfängerfeld?

Weil ein öffentliches Empfängerfeld den sozialen Graphen verraten würde.

Wenn jeder versiegelte Eintrag genau benennen würde, für wen er bestimmt ist, könnte ein Beobachter die Beziehungen zwischen Absendern und Empfängern abbilden, ohne ein einziges Byte Klartext zu lesen. Für vertrauliche Abläufe – eine Quelle, die eine Redaktion kontaktiert, ein versiegeltes Gebot, Beweismittel in Verwahrung – kann diese Offenlegung das ganze Risiko ausmachen.

Label 309 verwendet stattdessen umhüllte Schlüssel-Slots. Der Eintrag trägt verschlüsseltes Material, das nur die vorgesehenen Schlüsselinhaber öffnen können. Ein Beobachter kann sehen, dass ein Eintrag versiegelt ist und wie viele Slots er hat, aber keine lesbare Liste von Empfängern.

Das ist keine perfekte Anonymität, und es sollte auch nicht als solche verkauft werden. Slot-Anzahl, Veröffentlichungszeitpunkt und externe Metadaten können immer noch etwas verraten, und ein Absender, der die Zeitkorrelation aushebeln muss, muss abseits der sensiblen Zeitachse veröffentlichen. Was der Entwurf beseitigt, ist das offensichtlichste Leck: eine öffentliche Empfängerspalte auf einem dauerhaften Ledger.

Was, wenn ich mehrere Identitäten habe?

Dein Client probiert jede entsperrte Identität.

Du könntest eine Identität für persönliche Einträge führen, eine für ein Unternehmen, eine für die juristische Annahme und eine für einen hochriskanten vertraulichen Kanal. Jede hat ihren eigenen Seed und ihre eigenen Empfangsschlüssel, sodass ein Eintrag, der an eine davon versiegelt ist, für die anderen unsichtbar bleibt, bis die Schlüssel dieser Identität ausprobiert werden.

Ein Offline-First-Client verfolgt unabhängig, wie weit jede Identität den Eintrags-Feed durchsucht hat. Genau diese Unabhängigkeit erlaubt dir, später einen alten Seed zu importieren und den Client den gesamten Feed für diese Identität neu durchsuchen zu lassen – statt bei heute anzufangen und stillschweigend alles zu verpassen, was vor dem Import gesendet wurde.

Was passiert, wenn ich einen alten Identity Seed wiederherstelle?

Kompatible Software leitet dieselben Empfangsschlüssel aus dem Seed neu ab, deterministisch.

Das heißt, ein alter Seed kann alte versiegelte Einträge finden, solange die Einträge noch auf der Chain zum Durchsuchen liegen und der Chiffretext noch abrufbar oder gecacht ist. Der Client durchsucht den öffentlichen Feed erneut, entschlüsselt die versiegelten Umschläge probeweise und baut die Inbox-Ansicht für diese Identität neu auf. Den Seed wiederherzustellen stellt die Fähigkeit wieder her, für sie bestimmte Einträge zu erkennen – das Gateway hat keinen privaten Posteingang zum Zurückgeben.

Das ist einer der klarsten Gründe, warum der Seed so sehr zählt, und warum der Identity Seed weiterhin deine Aufmerksamkeit verdient. Verlierst du den Seed für eine Empfänger-Identität, können an sie adressierte versiegelte Einträge unlesbar werden – obwohl die öffentlichen Nachweise auf der Chain bleiben und weiterhin verifizieren. Verschlüsselung hat von Grund auf keine Wiederherstellungs-Hintertür; der Seed ist der Wiederherstellungspfad.

Kann ein Desktop-Client Einträge offline empfangen?

Er kann mit allem arbeiten, was er bereits synchronisiert hat.

CardanoWall Desktop – eine Open-Source-Rust-Anwendung, gebaut mit Tauri auf dem Open-Source-Rust-SDK (github.com/cardanowall) – ist genau darum herum gebaut. Sobald es Einträge synchronisiert und Chiffretext gecacht hat, listet, durchsucht, verifiziert und entschlüsselt es diese lokalen Daten ohne Netzwerkverbindung. Wenn ein Eintrag noch nicht synchronisiert oder ein Chiffretext noch nicht abgerufen wurde, braucht es das Netzwerk, um sie zu holen – und sagt das klar, statt stillschweigend zu scheitern.

Das spiegelt das Verhalten eines ernsthaften E-Mail-Clients: Offline heißt nicht, dass die Welt stehenbleibt. Dein lokaler Spiegel, dein Cache und dein Tresor werden zur Quelle der Wahrheit, bis das Netzwerk zurückkehrt. (Mehr zum Offline-Modell: Offline-Nachweise und CardanoWall Desktop.)

Wie sollte ich verifizieren, wer einen Eintrag gesendet hat?

Einen versiegelten Eintrag zu empfangen beweist nur, dass dein Schlüssel ihn öffnen kann. Es beweist nicht, wer ihn gesendet hat.

Urheberschaft ist in Label 309 optional. Trägt ein Eintrag eine Signatur, zeigt diese Signatur, dass ein bestimmter Schlüssel für den Eintrag eingestanden ist – aber du brauchst trotzdem Kontext, um zu entscheiden, wessen Schlüssel das ist. Ist ein Eintrag unsigniert, hat der Absender vielleicht bewusst vermieden, eine Identität daran zu binden, was genau das ist, was manche vertraulichen Abläufe verlangen.

Bestätige bei sensiblem Material Absenderschlüssel und Empfangsadressen auf einem anderen Weg: Führe ein Adressbuch, vergleiche Schlüssel-Fingerabdrücke und nutze ein Verzeichnis oder eine direkte Bestätigung, der du bereits vertraust. Verschlüsselung schützt den Inhalt; zu entscheiden, mit wessen Schlüssel du sprichst, ist eine separate, menschliche Vertrauensentscheidung. Die Mechanik des Adressbuchs wird in wie das Adressbuch funktioniert behandelt.

Was kann schiefgehen?

Der folgenschwerste Fehler ist, den Seed zu verlieren. Verlierst du den Identity Seed einer Empfänger-Identität, verlierst du womöglich die Fähigkeit, an sie adressierte Einträge zu entschlüsseln – dauerhaft, für diese Identität.

Der Rest ist betrieblicher Natur, und gute Software sollte ihn ehrlich offenlegen, statt ihn zu verbergen:

• der Chiffretext wurde nie erfolgreich hochgeladen;
• der Speicherort ist vorübergehend nicht verfügbar;
• der Absender hat die falsche Empfangsadresse verwendet;
• du hast die falsche Identität importiert;
• das lokale Gerät ist kompromittiert (ein bösartiges Programm auf einer entsperrten Maschine kann Geheimnisse im Arbeitsspeicher lesen – siehe Modus für öffentliche Computer);
• der Eintrag ist zu neu und hat die von dir geforderte Bestätigungstiefe nicht erreicht;
• der Eintrag ist gültig, aber unsigniert, sodass keine Absender-Identität feststeht.

Ein Nachweissystem gewinnt Vertrauen, indem es Unsicherheit zeigt, nicht indem es sie übertüncht.

Die Kurzfassung

Um versiegelte Einträge zu empfangen:

1. Teile eine Empfangsadresse.
2. Halte deinen Identity Seed sicher und gesichert.
3. Lass deinen Client den öffentlichen Label-309-Feed durchsuchen.
4. Lass ihn lokal probeentschlüsseln.
5. Öffne und verifiziere die Einträge, die deine Schlüssel entschlüsseln können.

Deine Inbox ist keine serverseitige Liste von Nachrichten, die an dein Konto adressiert sind. Sie ist eine lokale Ansicht versiegelter Einträge, die deine Identität öffnen kann – und genau das hält das Gateway aus deiner privaten Korrespondenz heraus.

Eine letzte ehrliche Anmerkung zu den Grenzen: Ein versiegelter Eintrag hält den Klartext für seine Schlüsselinhaber verschlüsselt, aber er garantiert keine Anonymität, und wer ihn entschlüsselt, kann den Klartext danach jederzeit weitergeben. Der Nachweis zeigt, dass bestimmte Bytes zu einer öffentlichen Zeit existierten. Er beweist weder Wahrheit noch Eigentum noch Urheberschaft – siehe was ein Nachweis nicht beweist.

Weiterführende Lektüre

• Was ist eine Empfangsadresse?
• Verifiziere einen Empfänger, bevor du eine Datei versiegelst
• Vertrauliche Offenlegung ohne öffentliche Dateien
• Der offene Standard und sein Referenzcode: label309.org und github.com/cardanowall. Label 309 ist beim Cardano-CIP-Prozess eingereicht und in Prüfung.