Sicherheitsmodell

Die Sicherheit von Label 309 beruht auf einer einzigen Idee: Ein Nachweis ist etwas, das die sich darauf verlassende Partei selbst überprüft. Ein Verifizierer vertraut der öffentlichen Cardano-Chain und, für Inhaltsansprüche, den Bytes, die ihm übergeben werden. Sonst vertraut er nichts: nicht dem Veröffentlichenden, keiner Domain, keinem Server, keinem Betreiber des Gateways, über das er die Transaktion zufällig gelesen hat. Jede Garantie auf dieser Seite folgt entweder aus dieser Haltung, markiert ihre Grenze oder benennt ein verbleibendes Risiko, das außerhalb davon liegt.

Diese Seite ist das Bedrohungsmodell für den Standard selbst: das Vertrauensmodell, unter dem ein konformer Verifizierer arbeitet, die Datenschutzeigenschaften einer unsignierten versiegelten PoE, die kryptografischen Pflichten, die jede Implementierung erfüllen MUSS, und die Grenzen, die das Wire-Format nicht (und nicht kann) überwinden. Sie beschreibt nicht die operative Sicherheit einer bestimmten Bereitstellung; sie beschreibt, was das Format jedem garantiert, der es korrekt implementiert.

Das Vertrauensmodell

Eine Partei, die sich auf einen Label-309-Nachweis verlässt und ihn prüft, stellt eine eng gefasste Frage: Existierten diese Bytes spätestens zum Zeitstempel dieses Blocks, und hängt dieses Urteil außer von Cardano vom Wohlverhalten irgendeiner Partei ab? Der Standard ist so gebaut, dass die Antwort auf die zweite Hälfte immer „nein“ lautet. Es gibt an keinem Schritt einen vom Aussteller kontrollierten Mittler: Das Chain-Gateway und das Speicher-Gateway, die ein Verifizierer heranzieht, sind nicht vertrauenswürdige Datenquellen, wo möglich kryptografisch geprüft und auf Aufnahme und Endgültigkeit gegengeprüft.

Worauf ein Verifizierer vertraut:

• Die öffentliche Cardano-Chain. Die Transaktion, ihre Metadaten unter Label 309 und ihre Blockzeit sind Fakten, die über jeden Cardano-Node hinweg repliziert sind. Ein Verifizierer liest sie über ein Gateway eigener Wahl und darf mehrere gegenprüfen.
• Die Inhalts-Bytes, sofern ein Inhaltsanspruch geprüft wird. Ein Hash im Datensatz bindet sich an eine bestimmte Bytefolge. Wer diese Bytes besitzt, berechnet den Hash neu und vergleicht; niemandes Wort, dass die Bytes passen, wird vorausgesetzt.

Worauf ein Verifizierer nicht vertraut:

• Den Veröffentlichenden. Label 309 hat kein issuer-Feld. Jede Wallet kann jeden Datensatz veröffentlichen; die Gültigkeit eines Datensatzes ist unabhängig davon, wer ihn eingereicht hat. Ein Verifizierer fragt nie „Ist dieser Aussteller vertrauenswürdig?“. Die Frage hat im Modell keinen Platz. Siehe die Invariante der Ausstellerunabhängigkeit unter Einführung.
• Einen Server oder eine Domain. Kein Schritt der Verifizierung kontaktiert einen vom Veröffentlichenden betriebenen Dienst. Es gibt keine kanonische Registry zum Nachschlagen, keinen Status-Endpunkt zum Abfragen, keine Identitätsinstanz, gegen die sich ein Schlüssel auflösen ließe.
• Einen Gateway-Betreiber. Die Cardano-, Arweave- und IPFS-Gateways, über die ein Verifizierer liest, sind austauschbar und werden inhaltlich geprüft (siehe unten). Ein Gateway ist ein Transportweg, keine Vertrauenswurzel.

Warum Gateways keine Vertrauenswurzel sind

Ein Verifizierer darf dieselbe Transaktion über jedes beliebige Cardano-Gateway lesen und denselben Inhalt über jedes beliebige Arweave- oder IPFS-Gateway. Keinem von ihnen wird zugetraut, ehrliche Daten zurückzugeben, denn was sie zurückgeben, ist unabhängig überprüfbar:

• Ein Gateway kann keinen Datensatz fälschen, der eine gültige Signatur trägt. Es besitzt den privaten Schlüssel (Private Key) des Signierenden nicht, und der Verifizierer berechnet die signierten Bytes neu und prüft sie selbst. Siehe Signaturen.
• Ein Gateway kann Inhalt unter einer inhaltsadressierten URI nicht unbemerkt ersetzen: Eine ipfs://-CID ist ein Multihash, den der Verifizierer aus den abgerufenen Bytes neu berechnet, und eine ar://-Transaktions-ID bindet sich unter dem Arweave-Konsens an die Daten. Bei einem konformen Eintrag ist die On-Chain-hashes-Map eine zweite, unabhängige Bindung an den Klartext, die zum Abrufzeitpunkt neu berechnet wird.
• Ein Gateway, das eine Transaktion vorenthält oder falsch meldet, wie tief sie eingebettet ist, ist eine Form von Denial of Service, keine Form von Fälschung. Ein Verifizierer, der über mehr als ein Gateway liest und bei Widerspruch abbricht, verwandelt „ein unehrliches Gateway“ in „Kollusion über jedes von ihm gewählte Gateway hinweg“, was er selbst kontrolliert.

Die Blocktiefe, also wie viele Bestätigungen ein Verifizierer verlangt, bevor er einen Datensatz als endgültig behandelt, ist Verifizierer-Richtlinie, kein von Label 309 vorgeschriebener Wert. Der Standard legt keine numerische Tiefe fest; die sich verlassende Partei setzt einen Schwellenwert nach ihrer eigenen Risikobereitschaft. Siehe Verifizierung.

Datenschutzeigenschaften der versiegelten PoE

Eine versiegelte PoE hält einen Klartext vertraulich und verankert zugleich seinen Zeitstempel. Über die Vertraulichkeit hinaus ist die Konstruktion so ausgelegt, dass die Chain so wenig wie möglich über die Nachricht und nichts über deren Empfängerkreis preisgibt. Es handelt sich um Wire-Format-Garantien: Sie gelten für jede korrekte Implementierung, weil sie Eigenschaften der Bytes sind, nicht einer bestimmten Bereitstellung.

Anonymität des Absenders bei unsignierter versiegelter PoE

Eine unsignierte versiegelte PoE, also ein Datensatz mit enc und ohne sigs, DARF die Identität des Absenders NICHT auf der Chain offenlegen. Ihre On-Wire-Bytes MÜSSEN unabhängig von den langlebigen Schlüsseln des Absenders sein.

Das gilt strukturell:

• Kein Signiererschlüssel auf der Leitung. Der Identitätsschlüssel eines Absenders gelangt nur über einen sigs-Eintrag auf die Chain. Ein Datensatz ohne sigs trägt überhaupt kein signiererseitiges Byte. Urheberschaft ist optional; Anonymität ist die Voreinstellung. Die langlebigen X25519- und Ed25519-Schlüssel des Absenders erscheinen in einem unsignierten Datensatz nie.
• Frische Kapselung pro Slot. Jeder Empfänger-Slot trägt pro Datensatz und pro Slot frisches KEM-Material, erzeugt zum Versiegelungszeitpunkt, nämlich den ephemeren öffentlichen X25519-Schlüssel in slot.epk auf dem x25519-Pfad oder den X-Wing-Geheimtext in slot.kem_ct auf dem mlkem768x25519-Pfad. Es steht in keinem Bezug zum langlebigen Schlüssel des Absenders und gibt nichts preis, was Datensätze einem gemeinsamen Urheber zuordnen würde.
• Gemischte Slots. Das Slot-Array wird vor der Veröffentlichung mit einem CSPRNG durchmischt, sodass die Positionsreihenfolge („primärer Empfänger zuerst“) kein Signal trägt.

Wer einen Datensatz später signiert, legt seinen Identitätsschlüssel nur in diesem Datensatz offen; er erscheint in keinem früheren unsignierten Datensatz, und keine Operation bildet das KEM-Material pro Slot der früheren Datensätze auf den Urheber zurück. Die Identitätsschlüssel X25519 und Ed25519 leiten sich über verschiedene HKDF-Kontextstrings aus dem Master-Seed ab, und ein öffentlicher Ed25519-Schlüssel kann einen öffentlichen X25519-Schlüssel weder ableiten noch ihm gleichen, sodass das Signieren eines Datensatzes die unsignierten nie verknüpft. Sich für Urheberschaft zu entscheiden, ist ein vorwärtsgerichteter Akt, keine rückwirkende Deanonymisierung.

Diese Invariante deckt nur die Bytes des label-309-Datensatzes ab. Die gebührenzahlende Cardano-Adresse in den Transaktionseingaben, die netzwerkseitige Identität des Erzeugers, wie sie ein Gateway sieht, und alle Metadaten im Off-Chain-Chiffretext-Blob liegen außerhalb des Wire-Formats. Label 309 lebt in den Metadaten, nicht in den Transaktionseingaben, und kann sich nicht gegen eine Korrelation über den Gebührenzahler verteidigen. Wer Anonymität des Gebührenzahlers benötigt, muss sie auf der Ebene der Transaktionskonstruktion angehen.

Unverknüpfbarkeit der Empfänger

Ein versiegelter Datensatz benennt seine Empfänger nie. Ein Empfänger erkennt eine Nachricht nur als die eigene, indem er einen Slot erfolgreich versuchsweise entschlüsselt; es gibt kein Adressatenfeld zum Auslesen. Daraus folgen zwei verschiedene Garantien, die nicht vermengt werden dürfen.

Die erste gilt für beide KEMs und für jeden Beobachter:

• Empfänger können einander nicht sehen. Jeder Slot ist ein eigenständig verpackter Schlüssel. Wer den eigenen Slot öffnet, erfährt nichts über einen anderen Slot und kann nicht erkennen, wer sonst adressiert wurde.
• Keine öffentlichen Empfängerschlüssel auf der Leitung. Nur die Kapselung pro Slot (epk oder kem_ct) und der verpackte Schlüssel erscheinen. Ein Beobachter ohne Kandidatenschlüssel kann Empfänger nicht aufzählen, er erfährt allein die Anzahl der Slots, die KEM-Familie (enc.kem) und die Unterscheidung versiegelt gegenüber offen.

Die zweite, nämlich Empfänger-Anonymität gegenüber einem Angreifer, der bereits eine Menge von Kandidaten-Empfängerschlüsseln besitzt und prüfen will, ob ein Slot an einen von ihnen adressiert ist, ist eine stärkere, KEM-spezifische Eigenschaft, und der Standard beansprucht sie nur für den klassischen Pfad:

• x25519 ist schlüsselprivat. Das epk pro Slot ist ein frischer ephemerer öffentlicher Schlüssel, statistisch unabhängig vom Empfängerschlüssel. Allein aus epk und wrap kann ein schlüsselbesitzender Angreifer ohne den passenden privaten Schlüssel nicht entscheiden, an welchen Kandidaten (falls überhaupt) ein Slot gerichtet ist.
• mlkem768x25519 beansprucht das nicht. Empfänger-Anonymität gegenüber einem schlüsselbesitzenden Angreifer ist eine eigenständige Eigenschaft, die nicht aus der IND-CCA-Sicherheit des hybriden KEM folgt, und sie wird für den X-Wing-Pfad nicht beansprucht, solange sie nicht eigenständig für X-Wing belegt ist. Eine Bereitstellung, deren Bedrohungsmodell Empfänger-Anonymität gegenüber einem schlüsselbesitzenden Angreifer verlangt, DARF sich für diese Eigenschaft NICHT auf den hybriden Pfad verlassen. Die ehrlichen Leckagen von oben, also Slot-Anzahl, KEM-Familie und versiegelt gegenüber offen, sind für beide KEMs identisch; mehr über die Empfänger wird auf keinem Pfad preisgegeben.

Bindung an den Klartext

Der On-Chain-Hash bindet sich an den Klartext, nicht an den Chiffretext. Wer eine versiegelte PoE entschlüsselt, berechnet den Klartext-Hash neu und vergleicht ihn mit der On-Chain-hashes-Map. Das bedeutet: Eine Speicherschicht, die einen manipulierten Chiffretext ausliefert, wird nach der Entschlüsselung erkannt, unabhängig vom Integritätsmodell der URI selbst. Der Zeitstempel-Anspruch ist ein Anspruch über den Klartext, auf den sich der Absender festgelegt hat, und nichts, was das Gateway tut, kann ihn mit anderen Bytes erfüllen.

Unabhängigkeit bei erneutem Senden

Die Signaturen eines Datensatzes stehen in dem Moment fest, in dem seine Transaktion eingereicht wird. Die Chain kennt keinen Begriff eines „erweiterten Signiererkreises“, der sich über Transaktionen hinweg ansammelt.

Wird ein identischer Datensatzkörper in einer separaten Transaktion mit einem anderen sigs-Satz erneut gesendet, entsteht ein separater, unabhängiger Datensatz mit eigener Blockzeit, niemals eine Erweiterung des Originals.

Wer einen bereits veröffentlichten Datensatz bestätigen möchte, veröffentlicht seinen eigenen Datensatz, der auf denselben Inhalt verweist oder über supersedes auf die vorherige Transaktion zeigt, signiert mit dem eigenen Schlüssel. Man hängt keinen Zeugen an den Datensatz einer anderen Person an. Folglich wird ein Angreifer, der die Bytes eines signierten Datensatzes in eine frische Transaktion kopiert, kein Mitsignierender des Originals: Er erzeugt einen späteren, doppelten Anspruch mit den von ihm gewählten sigs, und die frühere Blockzeit des Originals bleibt der kanonische Existenznachweis. Verifizierer und Indexer DÜRFEN zwei Transaktionen mit identischen Datensatzkörpern NICHT zu einer einzigen Ansicht „zusammengeführter Signierer“ verschmelzen; täten sie es, würde dies die per Datensatz geltende Blockzeit-Semantik verfälschen, auf die sich nachgelagerte Verbraucher verlassen.

Normative Regeln für Implementierungen

Die folgenden Punkte sind sicherheitsnormativ für jede konforme Implementierung, unabhängig von Sprache oder Plattform. Die Schlüsselwörter aus RFC 2119 / RFC 8174 werden im normativen Sinne verwendet.

Keine neuartige Kryptografie

Label 309 lässt bewusst nur gut analysierte Primitive zu, jede benannt in den Algorithmen-Registries und von einer auditierten Bibliothek implementiert. Eine Implementierung DARF keine eigene symmetrische Chiffre, keinen eigenen KDF, keine eigene Signaturkonstruktion und keine eigene Schlüsselverpackungs-Stanza einführen. Das Wire-Format ist eine Komposition aus Standardbausteinen, eben damit sich seine Sicherheit auf die Sicherheit dieser Bausteine zurückführen lässt.

Ausschließlich authentifizierte Verschlüsselung

Jede symmetrische Verschlüsselung in Label 309, sowohl die Inhaltsschicht als auch die Schlüsselverpackung pro Slot, ist AEAD. Es gibt nirgends im Format einen nicht authentifizierten Chiffremodus. Ein Entschlüsselnder, dessen AEAD-Tag-Prüfung fehlschlägt, MUSS einen strukturierten Fehler mit einem stabilen Code-Diskriminator zutage fördern und DARF NICHT dazu übergehen, nicht authentifizierte Bytes zurückzugeben. Die zusätzlichen authentifizierten Daten sind Teil der Tag-Berechnung, sodass eine falsche AAD genauso fehlschlägt wie ein falscher Schlüssel: Es gibt keinen Teilerfolgszustand, den man abtasten könnte.

Konstantzeitvergleich von Geheimnissen

Eine Vergleichsschleife, deren Laufzeit von geheimen Bytes abhängt, ist ein Orakel. Jede Gleichheitsprüfung über ein Geheimnis oder ein MAC-/AEAD-Tag MUSS in konstanter Zeit erfolgen:

• Der MAC über den Slot-Satz und jedes HMAC-Tag: Ein zeitliches Leck pro Byte bei einem 32-Byte-MAC kann unter wiederholten Angriffen das Tag rekonstruieren.
• Die AEAD-Tag-Verifizierung: Die decrypt-Funktion der zugrunde liegenden Bibliothek gibt bereits einen Fehlschlag zurück, ohne preiszugeben, welches Byte nicht stimmte; Implementierungen DÜRFEN diese Prüfung NICHT neu implementieren.
• Die Signaturverifizierung: Die verify-Funktion der Bibliothek verwenden, nie eine selbstgebaute Gleichung.

Ein nacktes ==/=== auf Byte-Arrays, das eine dieser Oberflächen berührt, ist ein Defekt. Wird jeder solche Vergleich über eine einzige typisierte Hilfsfunktion geleitet, lässt sich die Eigenschaft auditieren.

Die Konstantzeit-Disziplin erstreckt sich auf die Form der versuchsweisen Entschlüsselungsschleife, nicht nur auf einzelne Vergleiche. Um die Eigenschaft verborgener Empfänger zu wahren, MUSS ein Empfänger-Verifizierer alle Slots innerhalb des Durchlaufs eines einzelnen privaten Schlüssels verarbeiten, also eine konstante Anzahl von Slot-Operationen pro Schlüssel, ohne vorzeitigen Abbruch beim ersten Treffer, sodass ein netzwerkseitiger Beobachter mit Zeitmessung weder herleiten kann, welchen Slot-Index ein Schlüssel entpackt hat, noch ob überhaupt einer passte. Der Kandidatenschlüssel wird in konstanter Zeit ausgewählt. Die Gültigkeit des X25519-Anteils wird durch ein geheimnisunabhängiges Bit erfasst, kem_ok = NOT constantTimeEqual(shared, 0^32), das über einen Konstantzeitvergleich statt über einen vorzeitigen Verzweigungssprung berechnet wird; der KEK ist dann eine Konstantzeitauswahl zwischen dem echten KEK und einem Dummy-KEK, der unter demselben Salt und info aus einem gemeinsamen Geheimnis aus lauter Nullbytes abgeleitet ist, und kem_ok fließt in die Annahme des Slots ein (ok = kem_ok AND open_ok AND mac_ok), sodass ein Slot mit ungültigem ECDH nie angenommen werden kann, während die Schleife dennoch identische Arbeit leistet. Das Slot-Array wird in CSPRNG-gemischter Reihenfolge veröffentlicht, sodass die Wire-Position bereits kein Signal „primärer Empfänger zuerst“ trägt; zusammen mit dem konstantzeitigen Durchlauf erfährt ein Beobachter allein die Anzahl der Slots. Wer mehrere private Schlüssel besitzt (etwa archivierte Schlüssel über eine Identitätsrotation hinweg), iteriert Schlüssel × Slot und DARF über die Schlüssel hinweg vorzeitig abbrechen, was nur das schwache Signal „welcher Schlüssel passte“ preisgibt, MUSS aber über die Slots eines einzelnen Schlüssels konstantzeitig bleiben und dabei die Empfängerschlüssel-Hälfte des KEK-Salts pro Schlüssel neu ableiten, da beide KEMs das Salt auf die kanonische Wire-Kodierung dieses Schlüssels festlegen (genau der 32-Byte-X25519-Public-Key oder genau die festgelegten 1216-Byte-X-Wing-Public-Key-Bytes, niemals eine nicht-kanonische Neukodierung).

Strikte Ed25519-Verifizierung

Label-309-Signaturen MÜSSEN im strikten (kanonischen) Modus verifiziert werden. Ein laxer, cofactored Verifizierer akzeptiert bestimmte formbare Signaturen oder solche mit Schlüsseln niedriger Ordnung, die ein strikter Verifizierer ablehnt, was zwei konforme Implementierungen über denselben Datensatz uneins werden ließe und damit die Eigenschaft des einheitlichen Urteils bräche, von der der gesamte Standard abhängt. Der sprachübergreifende Konformitäts-Korpus fixiert einen Testvektor mit niedriger Ordnung exakt, um einen Verifizierer zu erkennen, der in den laxen Modus abgerutscht ist. Siehe Signaturen.

Niemals Geheimmaterial loggen

Seed-Bytes, abgeleitete private Schlüssel (Private Keys), Schlüsselverschlüsselungsschlüssel, Inhaltsverschlüsselungsschlüssel, aus einer Passphrase abgeleitetes Material und entschlüsselter Klartext DÜRFEN auf keiner Ebene in Logs gelangen. Eine pfadbasierte Redaktion in der Logger-Konfiguration ist notwendig, aber für sich allein nicht ausreichend: Ein Wert, der tiefer verschachtelt ist, als das Redaktions-Glob reicht, kann durchrutschen. Daher MÜSSEN Implementierungen außerdem jeden byte-typisierten Wert (Uint8Array, bytes und dergleichen) bedingungslos als opak-redigiert behandeln, selbst bei protokoll-öffentlichen Werten wie einer Nonce. Das günstigste Geheimnis, das man schützen kann, ist das, das nie in eine Logzeile gelangt.

Garantien der versiegelten PoE-Konstruktion

Drei weitere Eigenschaften sind spezifisch für die versiegelte PoE-Konstruktion. Sie sind sicherheitsnormativ für jede Implementierung, die einen versiegelten Datensatz erzeugt oder öffnet.

Der Slot-Satz-MAC ist ein ~128-Bit-Commitment

Der Slot-Satz-MAC ist es, der einen wiederhergestellten Inhaltsschlüssel zu einem Commitment auf die Slot-Menge macht, die der Empfänger getroffen hat: Ein böswilliger Absender kann keine zwei verschiedenen Slot-Mengen konstruieren, die ein einzelner Empfänger als „die seine“ akzeptiert. Die hier erforderliche Eigenschaft ist eingeschränktes Schlüssel-Commitment für den Inhaltsschlüssel des Umschlags im Sinne von RFC 9771, nämlich dass der wiederhergestellte Schlüssel an ein einzelnes Slot-Transkript bindet, nicht eine vollständige committing AEAD über beliebige Eingaben. Der Empfänger leitet aus einem Slot einen Schlüssel ab und verlangt dann, dass derselbe Schlüssel slots_mac über den Transkript-Hash der Slots reproduziert, bevor er den Slot als den eigenen behandelt. Konkret beruht das Commitment auf der Multi-Key-Kollisionsresistenz von

CEK ↦ HMAC-SHA-256( HKDF-SHA-256(CEK, info="cardano-poe-slots-mac-v1"), slots_hash )

für adversariell gewählte CEKs und Transkripte. Da der Angreifer sowohl den CEK als auch das Transkript kontrolliert, ist die maßgebliche Schranke die generische Kollisionsschranke (Geburtstagsschranke) auf der 256-Bit-HMAC-Ausgabe: Zwei (CEK, Transkript)-Paare zu finden, die denselben slots_mac ergeben, ist eine ~128-Bit-Suche, nicht das 256-Bit-Second-Preimage-Niveau. Eine generische Kollisionsmarge von 128 Bit ist das Sicherheitsniveau, auf das sich dieses Commitment stützt, und ist für das Bedrohungsmodell angemessen.

Das Transkript vor dem HMAC auf einen 32-Byte-slots_hash vorzuhashen, schwächt dies nicht: Eine slots_mac-Kollision impliziert entweder eine slots_hash-Kollision (eine SHA-256-Kollision) oder eine Kollision des geschlüsselten HMAC über gleiche slots_hash, beides auf dem ~128-Bit-Niveau. Die Manipulationsfestigkeit des Transkripts selbst erbt die 2^128-Kollisionsschranke von SHA-256: Jede Änderung an einem committeten Header-Feld oder Slot-Byte verändert slots_hash, und einen unveränderten slots_hash über ein anderes Transkript zu fälschen, ist genau diese ~128-Bit-Kollisionssuche. Eine direkte Folge ist, dass der Wrap pro Slot keine committing AEAD sein muss: Das Commitment liefert slots_mac, nicht der Wrap, sodass ein nicht committing Wrap (das voreingestellte ChaCha20-Poly1305) hier solide ist.

Die Sicherheit des Null-Nonce-Wrap beruht auf der Eindeutigkeit des Schlüssels pro Slot

Jeder Slot umhüllt den Inhaltsschlüssel unter einem Slot-Schlüsselverschlüsselungsschlüssel mit ChaCha20-Poly1305 bei einem Null-Nonce. Ein Null-Nonce ist nur deshalb sicher, weil der Schlüsselverschlüsselungsschlüssel pro Slot gilt und für genau einen Wrap verwendet wird: Jeder Slot zieht frische KEM-Zufälligkeit, sodass der Wrap-Schlüssel bei vernachlässigbarer Kollisionswahrscheinlichkeit pro Slot eindeutig ist. Die Sicherheitsbedingung ist genau die Eindeutigkeit des Schlüssels pro Slot, und ein Erzeuger DARF nichts einführen, was ein (key, nonce)-Paar wiederholen könnte: einen CSPRNG-Ausfall, der KEM-Zufälligkeit wiederholt, deterministische oder kollidierende Kapselung, die Wiederverwendung eines Slots über Datensätze hinweg, das Zwischenspeichern eines abgeleiteten Schlüssels nach (recipient, ephemeral) oder das Zusammenfassen zweier Vorkommen desselben Empfängers zu einem Slot.

Das teilt sich sauber in einen verifizierer-prüfbaren Anteil und eine reine Erzeugerpflicht:

• Dubletten innerhalb des Datensatzes werden vom Verifizierer abgelehnt. Ein Verifizierer MUSS verlangen, dass das Kapselungsmaterial innerhalb eines einzelnen slots[] eindeutig ist, also alle epk-Werte auf dem x25519-Pfad eindeutig, alle kem_ct-Werte auf dem mlkem768x25519-Pfad eindeutig. Eine Dublette wird abgelehnt, bevor irgendein KEM- oder AEAD-Primitive läuft, mit dem typisierten Code ENC_SLOTS_DUPLICATE_KEM_MATERIAL. Der Konformitäts-Korpus übt dies mit einem Datensatz, der zwei Slots mit gemeinsamem epk (oder kem_ct) trägt, und verlangt diese Ablehnung. Diese Ablehnung greift allein bei einem wiederholten epk / kem_ct; sie verbietet nicht, zweimal an denselben Empfänger zu versiegeln, da eine ehrliche Dublette für jedes Vorkommen weiterhin frische KEM-Zufälligkeit pro Slot zieht (siehe die Regel zu mehreren treffenden Slots weiter unten).
• Wiederverwendung über Datensätze und Schlüssel hinweg ist eine Erzeugerpflicht. Kein Verifizierer kann erkennen, dass ein Erzeuger KEM-Material über zwei verschiedene Datensätze oder Empfänger hinweg wiederverwendet hat; das liegt außerhalb der Bytes eines einzelnen Datensatzes und bleibt eine Erzeugerverantwortung. Würde eine künftige Revision Schlüsselwiederverwendung erlauben, müsste der Null-Nonce in derselben Änderung durch einen frischen Nonce ersetzt werden.

Mehrere treffende Slots: Auffüllen ist erlaubt, ein CEK-Konflikt nicht

Der private Schlüssel eines Empfängers DARF rechtmäßig mehr als einen Slot treffen. Denselben Inhaltsschlüssel an denselben Empfänger in mehreren Slots zu versiegeln, jeweils mit frischen flüchtigen Schlüsseln pro Slot, ist eine gültige Auffüll- und Datenschutztechnik: Sie hebt die sichtbare Slot-Anzahl an, ohne zu verraten, dass zwei der Slots denselben Empfänger teilen. Das ist verschieden von der Ablehnung doppelter Kapselung innerhalb des Datensatzes weiter oben: Eine ehrliche Dublette zieht frische KEM-Zufälligkeit, sodass ihr epk / kem_ct sich unterscheidet und sie ENC_SLOTS_DUPLICATE_KEM_MATERIAL nie auslöst. Ein Verifizierer MUSS daher den Inhaltsschlüssel des ersten treffenden Slots auswählen und DARF NICHT allein deshalb ablehnen, weil mehr als ein Slot getroffen hat.

Die einzige Anomalie, die ein Verifizierer ablehnen MUSS, sind zwei treffende Slots, die unterschiedliche Inhaltsschlüssel wiederherstellen, in konstanter Zeit verglichen. Die versuchsweise Entschlüsselungsschleife führt über alle Slots hinweg ein cek_conflict-Bit mit und fördert den einzelnen generischen Fehlschlag zutage, falls irgendein späterer Treffer einen Schlüssel wiederherstellt, der von dem bereits ausgewählten abweicht. Das ist Verteidigung in der Tiefe: Unter der Commitment-Eigenschaft oben ist ein Treffer mit abweichendem Schlüssel bereits unmöglich, denn er ist genau die Multi-Key-Kollision, die jene Eigenschaft ausschließt, sodass die Prüfung gegen eine fehlerhafte Implementierung oder eine künftige Abschwächung der Annahme „fail closed“ fällt. Das Negativ mit abweichendem Schlüssel ist nicht als Byte-Vektor konstruierbar (eines zu konstruieren wäre die Commitment-Kollision selbst), sodass die Eigenschaft durch implementierungsnahe Verhaltenstests statt durch einen Testvektor fixiert wird, neben einem positiven Testvektor für die rechtmäßige Empfänger-Dublette.

Ressourcengrenzen des Parsers vor jedem Primitive

Ein Verifizierer MUSS den Ressourcenverbrauch des Parsers begrenzen, bevor er irgendein KEM- oder AEAD-Primitive aufruft, damit ein übergroßer Umschlag keine Arbeit erzwingen kann, bevor er abgelehnt wird. Die Referenzgrenzen sind MAX_SLOTS = 1024 Slots und 65536 Bytes für den dekodierten enc-Umschlag, beide weit über der ~16-KiB-Metadatengrenze von Cardano, die jeden ehrlichen Datensatz beschränkt, sodass ein Datensatz, der eine der beiden Grenzen überschreitet, fehlgeformt ist. Eine zu hohe Anzahl wird mit ENC_SLOTS_TOO_MANY abgelehnt, ein zu großer Umschlag mit ENC_ENVELOPE_TOO_LARGE. Dies sind verifiziererseitig durchgesetzte, deployment-festgelegte Konstanten, keine Wire-Felder, und ein Deployment DARF sie verschärfen. Die entsprechende Schutzmaßnahme auf dem Passphrase-Pfad ist eine maximale Länge der rohen Passphrasen-Eingabe, durchgesetzt vor Normalisierung und Argon2id (Referenzgrenze 4096 UTF-8-Bytes, MAX_PASSPHRASE_INPUT_BYTES), sodass eine pathologische Passphrase keine Dienstverweigerung vor dem KDF antreiben kann.

Die Gültigkeit des öffentlichen X-Wing-Schlüssels begrenzt die hybride Untergrenze

Der hybride mlkem768x25519-KEM fällt als Untergrenze nie unter die klassische Sicherheit von X25519, doch diese Untergrenze ist auf gültig erzeugte Empfängerschlüssel beschränkt. XWing.Encapsulate MUSS die Gültigkeitsprüfung des öffentlichen Schlüssels aus der festgelegten X-Wing-Revision auf den Empfängerschlüssel anwenden und sich weigern, an einen Schlüssel zu kapseln, der sie nicht besteht, statt einen fehlgeformten Schlüssel zu behandeln, als trüge er die klassische Garantie. Wer die Prüfung auslässt, verwirkt die Untergrenze für diesen Empfänger; die Prüfung ist die Vorbedingung, unter der die Untergrenze hält.

Begrenzte Nutzlastgröße

Die Inhaltsschicht ist ein segmentierter STREAM: Der Klartext wird in 65536-Byte-Chunks zerlegt, von denen jeder unter dem Inhaltsschlüssel mit einer eigenen Zähler-Nonce versiegelt wird. Der 88-Bit-Zähler pro Chunk lässt 2^88 Chunks zu, und jeder Chunk bleibt klar innerhalb der Einzelaufruf-Grenze von RFC 8439; deshalb gibt es – anders als bei einem Single-Shot-AEAD über die gesamte Nutzlast – keine Schlüsselstrom-Kollision durch Zählerüberlauf, gegen die man sich schützen müsste, und das Format erlegt keine kryptografische Nutzlast-Obergrenze auf. Das Maximum, das ein Deployment durchsetzt, ist daher eine Denial-of-Service-Richtlinie, keine kryptografische Schranke: Erzeuger und Verifizierer SOLLTEN die Nutzlastgröße auf das beschränken, was zu ihren Ressourcen passt, und dies inkrementell durchsetzen, während der Stream geschrieben oder gelesen wird, und abbrechen, bevor eine übergroße Nutzlast gepuffert wird. Eine Abschneidung wird strukturell durch das Final-Flag pro Chunk erkannt – ein fehlender finaler Chunk, nachfolgende Daten oder ein zu kurzer nicht-finaler Chunk lassen die Entschlüsselung scheitern – und nicht durch eine Größenprüfung. Diese Haltung ist auf dem Slot-Pfad und dem Passphrase-Pfad identisch.

Algorithmenflexibilität als Sicherheitseigenschaft

Jede kryptografische Wahl in einem Label-309-Datensatz ist durch eine Zeichenkette aus einer erweiterbaren Registry benannt: der Hash, die AEAD, der KEM, der KDF, das Signaturverfahren. Das ist keine stilistische Entscheidung; es ist das Migrationssubstrat, das es dem Format erlaubt, jeden einzelnen Algorithmus zu überdauern.

Wird eine Primitive durch Kryptoanalyse geschwächt:

1. Die betreffende Registry erhält eine Nachfolger-Kennung. Am bestehenden Format ändert sich nichts; der neue Name ist additiv.
2. Bestehende Datensätze bleiben gültig. Ein Verifizierer erkennt für historische Datensätze weiterhin die alte Kennung; ihre Blockzeit-Ansprüche verschwinden nicht, nur weil ein neuerer Algorithmus existiert. Eine Implementierung DARF einen Datensatz, der sich allein auf einen inzwischen geschwächten Algorithmus stützt, als geringer abgesichert ausweisen, DARF ihn aber allein auf dieser Grundlage NICHT löschen oder ablehnen.
3. Neue Datensätze werden unter dem Nachfolger veröffentlicht. Wer Verteidigung in der Tiefe wünscht, DARF einen Inhalts-Hash unter zwei Algorithmen aus unterschiedlichen Entwurfsfamilien festlegen, sodass ein Bruch in einer einzelnen Familie den Beweiswert des Datensatzes nicht zum Einsturz bringt, wobei Datensätze mit nur einem Algorithmus weiterhin vollständig konform bleiben.

Weil Kennungen Zeichenketten sind und die Registries offen sind, ist die Migration zu Post-Quanten-Hashes, -KEMs oder -Signaturen eine additive Registry-Änderung, nie eine brechende Formatrevision. Der hybride Post-Quanten-KEM, der bereits in der Registry steht, ist ein Beispiel für diese Eigenschaft in Aktion, kein nachträglich angeschraubter Sonderfall.

Bekannte Grenzen des Standards

Dies sind keine Defekte, die in einer späteren Revision zu beheben wären; es sind inhärente Eigenschaften davon, Nachweise in einem dauerhaften öffentlichen Ledger zu verankern und auf langlebige Schlüssel mit Public-Key-Verfahren zu verschlüsseln. Ein ehrliches Sicherheitsmodell benennt sie.

On-Chain-Dauerhaftigkeit

Cardano-Metadaten sind dauerhaft und global repliziert. Ein veröffentlichter Label-309-Datensatz kann nicht gelöscht, redigiert oder ungültig gemacht werden: Diese Beständigkeit ist der ganze Sinn des Existenznachweises. Die Folge ist eine Verantwortung zum Zeitpunkt der Veröffentlichung: Ein Inhalts-Hash, eine an einen Stake gebundene Signatur oder alles andere, was unter Label 309 festgelegt wird, steht für immer auf der Chain. Label 309 lässt freie, beschreibende Metadaten bewusst aus dem Datensatz weg, um den On-Chain-Fußabdruck minimal zu halten, doch der Erzeuger MUSS verstehen, dass das, was er veröffentlicht, unwiderruflich ist, bevor er es veröffentlicht.

Die Anzahl der Empfänger ist sichtbar

Eine versiegelte PoE benennt ihre Empfänger nie, aber die Anzahl der Empfänger-Slots ist die Länge des Arrays und auf der Chain offen sichtbar, ebenso die KEM-Familie (enc.kem) und die Unterscheidung versiegelt gegenüber offen. Öffentliche Empfängerschlüssel liegen nicht auf der Leitung und die Slots werden durchmischt, doch ein Auffüllen zum Verbergen der Anzahl ist nicht Teil der Grundlinie. Ein Absender, für den die Empfängerzahl selbst sensibel ist, muss dieses Metadaten-Leck operativ berücksichtigen, etwa indem er den Slot-Satz selbst auffüllt oder separate Datensätze veröffentlicht.

Kein Widerruf pro Empfänger

Es gibt keine On-Chain-Primitive, um einem einzelnen Empfänger den Zugang zu einer bereits veröffentlichten versiegelten PoE zu entziehen. Sobald ein Datensatz auf einen öffentlichen Schlüssel verschlüsselt und verankert ist, ist diese Bindung dauerhaft. Das ist eine inhärente Eigenschaft der Public-Key-Verschlüsselung auf einen langlebigen Schlüssel, keine Lücke im Format. Ein für kompromittiert gehaltener Schlüssel wird vorwärtsgerichtet behandelt, indem neue Datensätze an einen frischen Schlüssel adressiert werden, optional unter Veröffentlichung eines ablösenden Datensatzes als Warnsignal nach dem Grundsatz „caveat emptor“, niemals indem man zurückgreift und ändert, was bereits auf der Chain steht.

Keine Forward Secrecy für Empfänger, von Grund auf so gewollt

Wer einen privaten Empfängerschlüssel besitzt, kann jede jemals an ihn adressierte versiegelte PoE entschlüsseln, für immer. Der Off-Chain-Chiffretext ist dauerhaft und es gibt keine Widerrufs-Primitive, sodass ein versiegelter Datensatz privat gegenüber der Welt, aber nicht gegenüber seinem Empfänger ist. Das ist das erwartete Verhalten beim Verschlüsseln auf einen langlebigen öffentlichen Schlüssel. Ein Absender, der die künftige Reichweite eines Empfängers begrenzen muss, verschlüsselt auf einen kurzlebigen Empfängerschlüssel statt auf einen langlebigen Identitätsschlüssel: eine absenderseitige Wahl, die das Format erlaubt, aber nicht vorschreibt.

Fehlschläge der versuchsweisen Entschlüsselung geben kein Schlüsselmaterial preis

Ein Empfänger findet seinen Slot durch versuchsweise Entschlüsselung. Intern, allein für die Diagnostik eines vertrauenswürdigen lokalen Aufrufers, tragen die Fehlerpfade unterschiedliche typisierte Codes: „kein Slot unter meinem Schlüssel geöffnet“ (WRONG_RECIPIENT_KEY), „ein Slot wurde geöffnet, aber kein Kandidatenschlüssel reproduzierte slots_mac“ (TAMPERED_HEADER) und „die Inhalts-AEAD schlug fehl, nachdem ein Schlüssel wiederhergestellt und der MAC verifiziert war“ (TAMPERED_CIPHERTEXT). Diese Codes haben keinen Orakelwert: Ein Angreifer ohne passenden privaten Schlüssel öffnet überhaupt keinen Slot, und jeder Fehlerpfad MUSS die zugrunde liegenden geheimen Bytes (Shared Secret, Schlüsselverschlüsselungsschlüssel, Inhaltsverschlüsselungsschlüssel) aus seiner Meldung und Ursachenkette ausschließen.

Ein nicht vertrauenswürdiger externer Aufrufer hingegen MUSS unabhängig davon, warum die Entschlüsselung fehlschlug, genau eine generische Fehlschlag-Form erhalten, und die externe Antwort DARF die drei Ursachen NICHT nach ihrer Form unterscheiden noch verraten, welcher Slot getroffen hat. Die internen Codes existieren für lokales Debuggen; sie DÜRFEN NICHT über eine unterscheidbare Antwort an einen Außenstehenden gelangen.

Das Timing-Modell ist bewusst eingegrenzt. Ein Verifizierer DARF an der Kein-Treffer-Prüfung zurückkehren, bevor die Inhaltsentschlüsselung beginnt, sodass ein Nicht-Empfänger (kein Slot öffnete) zeitlich von einem Empfänger unterschieden werden kann, dessen Slot öffnete, dessen Inhalts-Geheimtext aber nicht aufgeht. Diese Unterscheidung verrät allein Empfänger-versus-Nicht-Empfänger; sie verrät nie, welcher Slot getroffen hat, und kein Schlüsselmaterial. Ein einheitliches Timing zwischen dem Nicht-Empfänger-Fall und dem Fall des fehlerhaften Geheimtexts ist NICHT erforderlich, und ein Dummy-Inhaltsöffnen DARF NICHT vorgeschrieben werden, denn jedem Nicht-Empfänger die Kosten der Inhaltsentschlüsselung aufzuerlegen, brächte nichts ein. Die Konstantzeit-Garantie, die gilt, ist die Über-alle-Slots-Invariante (siehe Konstantzeitvergleich von Geheimnissen): Innerhalb des Durchlaufs eines einzelnen Schlüssels läuft die Schleife mit Konstantzeitvergleichen über alle Slots, sodass ein Beobachter nicht erfahren kann, welchen Slot ein gegebener Schlüssel entpackt hat, falls überhaupt einen, und jenseits der Empfänger-versus-Nicht-Empfänger-Unterscheidung allein die Slot-Anzahl erfährt.

Verwandte Seiten

• Einführung — die fünf Invarianten, darunter ausstellerunabhängig und eigenständig überprüfbar.
• Signaturen — strikte Ed25519-Verifizierung und das fail-soft ausgelegte Urheberschaftsmodell.
• Versiegelte PoE — der Verschlüsselungsumschlag und die hier zusammengefassten Datenschutzeigenschaften.
• Algorithmen-Registries — die benannten Kennungen, die Algorithmenflexibilität möglich machen.
• Verifizierung — die Pipeline, die Richtlinie zur Bestätigungstiefe und der Fehlerkatalog.