Algorithmus-Register

Jede kryptografische Festlegung in Label 309 trägt einen Zeichenketten-Bezeichner aus einem erweiterbaren Register, etwa sha2-256, chacha20-poly1305-stream64k, EdDSA und so weiter. Ein Datensatz enthält weder eine rohe Algorithmusnummer noch eine stillschweigende Annahme; er gibt an, welches Verfahren verwendet wurde, und ein Verifizierer schlägt diesen Bezeichner nach. Genau das ist der Mechanismus hinter der Invariante algorithmenflexibel: Die Register dürfen mit der Zeit wachsen, und trifft ein Verifizierer auf einen Bezeichner, den er nicht implementiert, weist er den Datensatz mit einem stabilen, typisierten Fehler zurück. Er stürzt nie ab, und er akzeptiert nie stillschweigend etwas, das er nicht prüfen kann.

Diese eine Regel macht den Umstieg auf Post-Quanten-Algorithmen additiv. Ein neuer Bezeichner ist eine neue Zeile in einer Tabelle, nicht eine neue Version des Wire-Formats. Ältere Datensätze lassen sich weiterhin exakt wie zuvor verifizieren, und ältere Verifizierer scheitern kontrolliert (fail closed) an Datensätzen, für deren Verständnis sie nie gebaut wurden.

Hash

Der Inhalts-Hash ist der primäre Anspruch jedes Datensatzes, daher trägt das Hash-Register die größte Last. Beide registrierten Funktionen erzeugen einen 32 Byte langen Digest, und eine konforme Implementierung muss beide unterstützen.

Wer einen Datensatz erzeugt, DARF denselben Inhalt zur zusätzlichen Absicherung (defense in depth) unter beiden Funktionen hashen; für einen gültigen Datensatz genügt ein einzelner Hash.

Merkle-Commitment

Um sich mit einem einzigen On-Chain-Wurzelwert auf eine geordnete Liste von Blättern festzulegen, registriert Label 309 einen Merkle-Commitment-Bezeichner. Es handelt sich um die bei IANA registrierte Zeichenkette für den binären SHA-256-Merkle-Baum, der dieselbe Domänentrennung über das Blatt-Präfix (0x00) und das Präfix für innere Knoten (0x01) nutzt, die Kollisionen zwischen Blättern und Knoten verhindert.

Ein Baum mit nur einem Blatt legt sich auf SHA-256(0x00 ‖ leaf) fest, nicht auf das bloße Blatt. Ein Nachweis für eine einzelne Datei MUSS daher einen einfachen Hash-Bezeichner verwenden, niemals einen Baum mit einem einzigen Blatt.

AEAD

Das AEAD-Register legt fest, welches Inhaltsformat auf der Übertragungsstrecke (on the wire) eine versiegelte Nutzlast schützt – das Feld enc.aead. Unter enc.scheme: 1 ist genau ein Bezeichner registriert, und es ist ein segmentiertes Format, keine Single-Shot-Chiffre.

chacha20-poly1305-stream64k ist ChaCha20-Poly1305 (RFC 8439) im 64-KiB-segmentierten STREAM-Layout der age-v1-Spezifikation: Der Klartext wird in 65536-Byte-Chunks zerlegt, und jeder Chunk wird unter dem Inhaltsschlüssel mit einer 12 Byte langen Nonce pro Chunk uint88_be(counter) ‖ final_flag versiegelt (Zähler ab 0, final_flag 0x01 beim letzten Chunk) und mit einer leeren AAD pro Chunk, was einen 16 Byte langen Tag pro Chunk erzeugt. Die 24 Byte lange enc.nonce ist keine Chunk-Nonce: Sie ist das umschlageindeutige Salt der Inhaltsschlüssel-HKDF, und genau das hält die Zähler-Nonces sicher – der Inhaltsschlüssel ist einmalig, sodass nie zwei Streams ein (key, nonce)-Paar teilen und zustandslose Erzeuger Nonces nie über Umschläge hinweg abstimmen müssen. Das segmentierte Layout erlaubt es einem Verifizierer, eine große Nutzlast inkrementell und mit begrenztem Speicher zu authentifizieren und freizugeben, und das Final-Flag macht eine Abschneidung erkennbar. Die Schreibweise auf der Übertragungsstrecke ist exakt chacha20-poly1305-stream64k; abweichende Schreibweisen DÜRFEN NICHT erzeugt werden. Die vollständige Konstruktion steht unter Versiegelte PoE.

chacha20-poly1305-stream64k ist der einzige Bezeichner, der als Inhaltsformat auf der Übertragungsstrecke auftreten darf. Eine separate Konstruktion, chacha20-poly1305 (RFC 8439, 32 Byte Schlüssel / 12 Byte Nonce / 16 Byte Tag), dient intern dazu, innerhalb der versiegelten Konstruktion einen empfängerspezifischen Schlüssel zu umhüllen: ein 12 Byte langer Null-Nonce, AAD auf das info-Label des gewählten KEM gesetzt, was einen 48 Byte langen wrap erzeugt (32 Byte umhüllter Schlüssel + 16 Byte Tag). Sie ist ein Baustein, kein Übertragungsbezeichner, und ein Datensatz, der sie in enc.aead angibt, MUSS zurückgewiesen werden. aes-256-gcm ist benannt, aber inaktiv; es ist für ein künftiges Verschlüsselungsprofil (enc.scheme: 2) reserviert, und ein v1-Verifizierer weist jeden Datensatz zurück, der es auswählt.

KEM

Das KEM-Register erfasst die Schlüsselkapselungsmechanismen, mit denen eine versiegelte Nutzlast an bestimmte Empfänger adressiert wird. Label 309 registriert einen klassischen, kurvenbasierten KEM sowie ein hybrides Post-Quanten-Verfahren, das ab der ersten Veröffentlichung aktiv ausgeliefert wird.

mlkem768x25519 ist die X-Wing-Konstruktion aus draft-connolly-cfrg-xwing-kem-10: Sie kombiniert ML-KEM-768 (FIPS 203) mit X25519 (RFC 7748), sodass ein Angreifer beide Verfahren brechen muss, um das gemeinsame Geheimnis zu gewinnen. Der öffentliche Schlüssel besteht aus dem ML-KEM-768-Kapselungsschlüssel, verkettet mit dem öffentlichen X25519-Schlüssel (1184 B ‖ 32 B = 1216 B); das Secret ist ein 32 Byte langer Seed, aus dem der vollständige Schlüssel abgeleitet wird. Der Geheimtext für jeden Empfänger ist der ML-KEM-768-Geheimtext, verkettet mit einem flüchtigen öffentlichen X25519-Schlüssel (1088 B ‖ 32 B = 1120 B), und die beiden gemeinsamen Geheimnisse werden vom X-Wing-Kombinierer SHA3-256 (FIPS 202) zum finalen 32 Byte langen Geheimnis verbunden. Label 309 nutzt X-Wing als Black-Box-KEM, also Kapseln, Entkapseln, das 32 Byte lange gemeinsame Geheimnis, und stützt sich auf keine Eigenschaft des internen Hashens im Kombinierer. Der Bezeichner wird ohne interne Bindestriche geschrieben, um der etablierten X-Wing-Schreibweise zu entsprechen.

Der Hybrid wird je Datensatz über den Verschlüsselungs-Header ausgewählt, unabhängig von der Inhalts-AEAD. Da er bereits registriert ist, ist Post-Quanten-Vertraulichkeit eine Frage des Auswählens des passenden Bezeichners und nicht des Wartens auf eine neue Version des Wire-Formats.

Ein einzelner Datensatz benennt genau ein enc.kem, und jeder Slot verwendet die Form dieses KEM; ein Slot mit falscher Form ist ENC_SLOT_INVALID_SHAPE, ein epk (≠ 32 B) oder kem_ct (≠ 1120 B) mit falscher Länge ist KEM_EPK_LENGTH_MISMATCH / KEM_CT_LENGTH_MISMATCH, und ein nicht registriertes enc.kem ist UNSUPPORTED_KEM_ALG. Das Kapselungsmaterial muss zudem innerhalb eines slots[] eindeutig sein: Alle epk-Werte (bei x25519) oder alle kem_ct-Werte (bei mlkem768x25519) MÜSSEN sich unterscheiden. Eine Dublette innerhalb des Datensatzes wird mit ENC_SLOTS_DUPLICATE_KEM_MATERIAL zurückgewiesen, bevor irgendein KEM- oder AEAD-Primitive läuft, denn ein wiederholtes epk oder kem_ct bricht die Eindeutigkeit des Slot-Schlüssels, auf die der Null-Nonce-wrap angewiesen ist. Ein Verifizierer begrenzt zudem den Ressourcenverbrauch des Parsers, bevor irgendein Primitive läuft: Ein Umschlag, dessen slots[] die Referenzgrenze von 1024 Slots überschreitet, ist ENC_SLOTS_TOO_MANY, und ein dekodierter enc-Umschlag, der 65 536 Bytes überschreitet, ist ENC_ENVELOPE_TOO_LARGE. Beide Grenzen liegen weit über der ~16-KiB-Metadatengrenze von Cardano, die jeden ehrlichen Datensatz deckelt; sie sind verifiziererseitig durchgesetzte, deployment-festgelegte Konstanten, keine Wire-Felder, und Deployments DÜRFEN sie verschärfen.

KDF

Das KDF-Register benennt die Schlüsselableitungsfunktionen. hkdf-sha256 leitet Schlüssel innerhalb der versiegelten Konstruktion ab; argon2id streckt eine menschenlesbare Passphrase gegen Brute-Force-Angriffe und unterliegt einer verpflichtenden Mindestanforderung an die Parameter.

Die Argon2id-Mindestanforderung ist normativ: Eine passphrasengeschützte Nutzlast MUSS mindestens 64 MiB Arbeitsspeicher, mindestens drei Iterationen und mindestens eine Lane verwenden. Wer einen Datensatz erzeugt, DARF stärkere Parameter wählen; diese reisen mit dem Datensatz mit, damit ein Verifizierer die Ableitung nachvollziehen kann. Wo die Plattform es unterstützt, SOLLTE ein Erzeuger die Parallelität p = 4 setzen, das zweite empfohlene Profil aus RFC 9106 §4, während ein Verifizierer jedes p ≥ 1 akzeptieren DARF, vorbehaltlich der Deployment-Obergrenzen. Diese Obergrenzen sind ein implementierungsseitiges SOLLTE, kein DARF: Ein Verifizierer SOLLTE obere Schranken gegen eine verifiziererseitige Dienstverweigerung durch absurde Parameter durchsetzen und dabei ENC_PASSPHRASE_PARAMS_EXCEED_POLICY melden. Die Obergrenze ist hardwareabhängig und nicht normativ und DARF NICHT mit dem Mindestanforderungs-Code ENC_PASSPHRASE_ARGON2_PARAMS_TOO_LOW vermengt werden.

Nur argon2id ist auf der Übertragungsstrecke wählbar: Es ist der einzige Bezeichner, den ein Datensatz in enc.passphrase.alg benennen darf. hkdf-sha256 ist ein interner Baustein, nämlich der feste Extract-and-Expand-Schritt hinter der Seed-zu-Schlüssel-Ableitung, der Ableitung des Slot-KEK, des Schlüssels für den Slot-Satz-MAC, des Schlüssels für den Passphrase-Commitment-MAC und der Inhaltsschlüssel-Ableitung, und es trägt keinen Übertragungsbezeichner. Ein Datensatz, der hkdf-sha256 in enc.passphrase.alg benennt, MUSS zurückgewiesen werden: HKDF ist für Eingaben mit hoher Entropie gedacht, nicht für das Strecken einer Passphrase mit geringer Entropie.

Interne Labels sind Konstanten, nie auf der Übertragungsstrecke

Die versiegelte Konstruktion bezieht ihre Domänentrennung aus einer festen Menge von Label-Literalen: HKDF-info-Tags und SHA-256-Präfixe (KEK-Salt-Präfixe, Transkript-Präfixe und das Element-Hashes-Präfix). Jedes ist eine Konstante von enc.scheme: 1, exaktes ASCII ohne Terminator und ohne Längenpräfix; keines wird je serialisiert, und keines ist über irgendein Register wählbar. Es gibt elf:

Beide KEK-Salts teilen eine einzige markierte Hash-Form – SHA-256(label ‖ enc.nonce ‖ <Slot-KEM-Material> ‖ pub_R) – unter ihrem jeweils KEM-eigenen Label. Diese Labels unterscheiden sich von den Seed-Ableitungs-info-Strings unter Schlüssel und vom Domänenpräfix der Datensatzsignatur unter Signaturen: Die Menge ist kollisionsfrei und präfixfrei, sodass kein versiegelungsspezifisches Label einem Label für die Ableitung langlebiger Schlüssel gleicht – oder dessen Byte-Präfix ist –, und Identitätsschlüssel-Ableitung und datensatzspezifische Schlüsselumhüllung kollidieren nie. Ein Verifizierer MUSS jedes Literal Byte für Byte verwenden; ein einziges abweichendes Byte ergibt einen slots_mac, ein Commitment oder einen AEAD-Tag, den der ehrliche Erzeuger nicht reproduzieren kann. Die Byte-genaue Konstruktion, die jedes Label verbraucht, steht unter Versiegelte PoE.

Signatur

Label 309 registriert einen Signaturalgorithmus. Signaturen zur Urheberschaft sind stets optional, doch wenn sie vorhanden sind, werden sie als COSE_Sign1 (RFC 9052) mit Ed25519 übertragen.

Die Verifikation ist gemäß RFC 8032 §5.1.7 streng: Implementierungen MÜSSEN nicht-kanonische Signaturkodierungen und Punkte kleiner Ordnung (small-order points) ablehnen (keine Kofaktor-Bereinigungserweiterung). Das entspricht den konservativen Akzeptanzkriterien, die über Cardano-Wallets hinweg verwendet werden, sodass eine Signatur, die unter einer konformen Implementierung verifiziert, unter allen konformen Implementierungen verifiziert.

Die Signaturunterstützung ist unabhängig vom Inhaltsanspruch. Ein Verifizierer, der den Signaturalgorithmus eines Datensatzes nicht implementiert, markiert diesen Signatur-Slot als nicht unterstützt und lässt den Zeitstempel und den Inhaltsanspruch vollständig gültig: Ein unbekannter Signaturalgorithmus macht den Datensatz selbst niemals ungültig.

Reservierte Bezeichner

Einige Bezeichner sind benannt, aber noch nicht aktiv. Sie markieren den vereinbarten Migrationspfad, damit künftige Profile stabile, vorab festgelegte Namen statt improvisierter Zeichenketten verwenden. Wer einen Datensatz erzeugt, DARF sie konformerweise NICHT ausgeben, und ein konformer Verifizierer MUSS jeden Datensatz, der einen davon verwendet, mit dem entsprechenden typisierten Fehler zurückweisen.

ml-kem-768 ist der reine Post-Quanten-KEM, abzugrenzen vom registrierten Hybrid mlkem768x25519; ausgeliefert wird in Label 309 der Hybrid, nach dem Grundsatz, dass ein klassischer Rückfall (fallback) auch dann erhalten bleiben sollte, wenn der Post-Quanten-Anteil hinzukommt.

Algorithmenflexibilität und Migration

Einen Algorithmus hinzuzufügen ist ein in sich abgeschlossener, additiver Vorgang: Sie verweisen für das Verfahren auf einen öffentlichen Standard, fügen den Bezeichner dem passenden Register hinzu, stellen eine geprüfte und gut begutachtete Implementierung bereit und veröffentlichen ein sprachübergreifendes Konformitätsfixture, damit unabhängige Implementierungen Byte für Byte übereinstimmen. Die Version des Wire-Formats ändert sich dabei nicht, weil sich das Schema nicht ändert. Es wächst lediglich die Menge der erkannten Zeichenketten.

Die Konsequenzen ergeben sich unmittelbar aus dem Aufbau des Registers:

• Alte Datensätze bleiben verifizierbar. Ihre Bezeichner stehen weiterhin im Register, sodass jeder bestehende Datensatz exakt so verifiziert wird wie an dem Tag, an dem er veröffentlicht wurde.
• Alte Verifizierer scheitern kontrolliert. Ein Verifizierer, der älter ist als ein neuer Bezeichner, weist Datensätze, die ihn verwenden, mit einem stabilen UNSUPPORTED_*-Fehler zurück, statt zu raten: Es gibt keinen Weg zu einer stillschweigenden Annahme.
• Post-Quanten-Unterstützung ist additiv. Weil mlkem768x25519 bereits registriert ist und sich neue KEMs und Signaturen in denselben Mechanismus einfügen, ist der Übergang zu Post-Quanten-Verfahren ein Wachstum des Registers und keine brechende Migration.

Eine Versionsanhebung des Wire-Formats bleibt echten, brechenden Schemaänderungen vorbehalten: einem neuen Pflichtfeld, einem entfernten Feld, einem geänderten Typ. Ein Wachstum des Registers erfüllt diese Bedingung nie, und genau das erlaubt es dem kryptografischen Katalog, sich weiterzuentwickeln, ohne je einen veröffentlichten Existenznachweis im Stich zu lassen.