Zusammenfassung

  • CFRG veröffentlichte am 7. September 2026 Revision 14 von draft-irtf-cfrg-pairing-friendly-curves. Das Dokument ist ein aktiver Internet-Draft einer IRTF-Forschungsgruppe mit vorgesehener Kategorie Informational, kein RFC und kein IETF-Standard.
  • Die Revision definiert normative Serialisierung und Deserialisierung für Punkte auf BLS12-381 und BLS48-581 sowie für Skalare dieser Kurven und von BN462. Der Decoder prüft kanonische Koordinaten, Kurve und Untergruppe, bevor er ein Gruppenelement oder INVALID liefert.
  • Drei Entscheidungen bleiben beim aufrufenden Protokoll: welche Punktform es annimmt, ob das Identitätselement zulässig ist und ob der Nullskalar zulässig ist. Die beiden letzten Fragen sind unabhängig.
  • Gegenüber Revision 13 entfernt der neue Text die allgemeine Empfehlung, die Identität standardmäßig abzulehnen, trennt die Nullregel davon und ergänzt die ausdrückliche Wahl der Punktform. Eine normative BN462-Punktkodierung fehlt absichtlich, weil die untersuchte Praxis nicht konvergiert ist.
  • Daniel Kade schlägt ein Annahmeprofil mit sieben Feldern vor. Es ist ein Analysevorschlag dieses Artikels und keine Forderung des Entwurfs oder der CFRG.

Mathematische Gültigkeit beendet den Protokollvertrag nicht

„Validierung“ bezeichnet in Kryptospezifikationen oft zwei verschiedene Arbeiten. Zuerst ist zu klären, ob Länge und Metadatenbits stimmen, die Koordinate kanonisch ist, der rekonstruierte Punkt auf der vorgesehenen Kurve liegt und der vorgeschriebenen Untergruppe angehört. Danach folgt eine semantische Frage: Darf dieses gültige Element in diesem Feld einer Nachricht, eines Schlüssels oder eines Beweises stehen?

Revision 14 präzisiert die erste Ebene. Die Punkt-Deserialisierung gibt entweder ein Gruppenelement oder INVALID zurück. Eine Koordinate ab dem Feldmodul wird nicht stillschweigend reduziert, sondern verworfen. Danach folgen Kurvengleichung und Untergruppenprüfung. Selbst Punktarten mit gleicher Eingabelänge werden nicht über den falschen Kurvenpfad austauschbar gemacht.

Bei Skalaren muss der kodierte Integer unter der Ordnung des Skalarfelds liegen. Null besitzt folglich eine kanonische Darstellung. Daraus folgt aber nicht, dass Null als geheimer Schlüssel, Challenge, Koeffizient oder Zwischenwert zugelassen ist. Der allgemeine Decoder kennt die Rolle dieses Feldes nicht.

Zwei Implementierungen können deshalb den gemeinsamen Decoder korrekt implementieren und trotzdem nicht interoperieren. Die eine verwirft den mathematisch gültigen Rückgabewert, die andere nimmt ihn an; oder beide nehmen denselben Punkt an, behandeln aber seine zwei empfangenen Darstellungen als verschiedene Objekte. Nach dem Decoder beginnt eine zweite Konformitätsgrenze.

Drei Schalter sind kein gemeinsamer „Strict Mode“

Die erste Entscheidung betrifft die Punktform. Revision 14 verlangt vom aufrufenden Protokoll eine Aussage: nur komprimiert, nur unkomprimiert oder beides. Werden beide Formen akzeptiert, kann ein mathematischer Punkt zwei gültige Bytefolgen besitzen. Wenn eine Anwendung die empfangenen Bytes hasht, signiert, direkt vergleicht oder als Datenbank- beziehungsweise Cache-Schlüssel verwendet, wird eine Darstellungsfrage zur Zustandsfrage.

Die zweite Entscheidung betrifft das Identitätselement. Manche Konstruktionen haben einen eigenen Grund, es auszuschließen. Der BLS-Signaturentwurf verwirft die Identität bei der Schlüsselprüfung im Zusammenhang mit dem ungültigen geheimen Nullschlüssel und einer Identitätssignatur. In einer anderen algebraischen Konstruktion kann die Identität eine legitime Rolle spielen. Revision 14 setzt daher keinen universellen Standard, sondern verweist auf Semantik und Bedrohungsmodell.

Die dritte Entscheidung gilt dem Nullskalar und steht für sich. Revision 13 bezeichnete die Ablehnung der Identität als empfohlenen Standard und band die Behandlung der Null an dieselbe protokollabhängige Politik. Revision 14 löst diese Verbindung. RFC 9591 zeigt die Trennung praktisch: Seine Element-Deserialisierung lehnt Identitätselemente ab, während die Skalar-Deserialisierung keine entsprechende Nullsperre hinzufügt.

Ein Protokoll kann also nur komprimierte Punkte annehmen, die Identität verwerfen und Null in einem bestimmten Feld zulassen. Ein anderes kann beide Punktformen annehmen, die Identität in einer Operation verwenden und Nullskalare ablehnen. Ein einziger Bibliotheksschalter würde diese Semantik verdecken und die Entscheidung von der Spezifikation in generischen Code verschieben.

BN462 markiert die Grenze des gemeinsamen Formats

Für BLS12-381 und BLS48-581 definiert der Entwurf Punktformate, für BN462 nicht. Der Primmodul des BN462-Basiskörpers beansprucht 462 Bits. In 58 Bytes mit insgesamt 464 Bits bleiben nur zwei Bits frei, während das gemeinsame komprimierte Schema drei Metadateninformationen unterbringen muss.

Der informative Anhang dokumentiert unvereinbare Praktiken in vorhandener Software: einen Typ-Byte nach SEC1-Art, ein separates Flag-Byte sowie gepackte Darstellungen ohne dieselbe Metadatenkonvention. Nach Angaben der Autoren verlangen die untersuchten Spezifikationen keine BN462-Punktkodierung; die Praxis sei nicht konvergiert. Revision 14 erklärt daher keine dieser Varianten zum normativen gemeinsamen Weg.

Das heißt weder, dass es keine BN462-Implementierungen gibt, noch dass ein genanntes Format unsicher ist oder bestehende Systeme geändert werden müssen. Die Aussage ist enger: Wer BN462-Punkte überträgt, muss eine andere Kodierungsspezifikation exakt benennen oder die eigene Konvention vollständig definieren. Ein Verweis nur auf Revision 14 schließt den Bytevertrag nicht.

Lokale Freiheit braucht eine sichtbare Akte

Die Entwicklungsgeschichte erklärt die Zentralisierung. Issue 74 im CFRG-Repository verlangte eine maßgebliche Serialisierungsdefinition statt widersprüchlicher Kopien. Pull Request 108 brachte benannte Verfahren, Zugehörigkeitsprüfungen, Protokollentscheidungen und Testvektoren in Revision 14. Nachrichten auf der CFRG-Liste informierten Autoren abhängiger Dokumente. Die Entwürfe zu BBS-Signaturen und COSE-Darstellungen von BLS-Schlüsseln zeigen, dass diese Abhängigkeit praktisch besteht.

Eine kleine gemeinsame Schicht kann die Mathematik stabilisieren, ohne die Semantik sämtlicher Anwendungen zu regieren. Lokale Entscheidungen dürfen lokal bleiben, müssen aber dokumentiert sein. Eine Wahl, die ausschließlich im Standardwert einer Bibliothek lebt, ist keine Modularität. An einer Netzgrenze erscheint sie als undokumentierter Fork.

Ich schlage deshalb vor, dass jede aufrufende Spezifikation ein siebenstelliges Annahmeprofil veröffentlicht: genaue Revision des Kurvendokuments, Kurve, angenommene Punktformen, Identitätsregel, Nullskalarregel, Pfad der Untergruppenprüfung und bei BN462-Punkten die genaue externe Kodierungsreferenz. Dasselbe Profil kann in Interoperabilitätstests und Kompatibilitätsberichten erscheinen.

Name und Aufbau dieses Profils sind Daniel Kades Vorschlag; Revision 14 schreibt sie nicht vor. Es soll lokale Entscheidungen nicht vereinheitlichen, sondern ihren Eigentümer, ihre Version und ihre Folgekosten sichtbar machen.

Quellen