Zusammenfassung

  • Revision 12 des BBS-Entwurfs erlaubt den Nachweis der Kenntnis einer Signatur über mehrere Nachrichten, während der Inhaber nur ausgewählte Nachrichten offenlegt. Die Unverknüpfbarkeit gilt für den randomisierten Proof-Wert; header, presentation_header, offengelegte Werte, Anzahl und Positionen, Signer-Schlüssel, Netzwerkadresse und Anwendungsdaten können weiter korrelieren.
  • Ein gültiges ProofVerify ist deshalb ein begrenzter kryptografischer Beleg. Es beweist nicht automatisch die menschliche Identität, die Prüfung bei Ausstellung, aktuellen Status, Vollständigkeit, Berechtigung, Unverknüpfbarkeit der gesamten Interaktion oder den späteren Erfolg.

Ein Privacy-Dashboard zeigt zwei unterschiedliche Proofs und setzt den Status auf grün. Ein Fraud-System verbindet dieselben Sitzungen in Sekunden. Es musste weder die Paarung brechen noch eine verborgene Nachricht rekonstruieren. Es kombinierte Werte, die nie Teil des engen Unverknüpfbarkeitsversprechens waren.

Genau darin liegt die operative Bedeutung von draft-irtf-cfrg-bbs-signatures-12. Der Entwurf beschreibt eine starke Mehrnachrichtensignatur und einen Zero-Knowledge-Kenntnisnachweis. Anschließend grenzt er die Eigenschaft ausdrücklich auf den Proof-Wert ein. Eine Produktfreigabe, die nur den ersten Teil zitiert, ändert die Aussage.

Konkrete Testvektoren machen Code prüfbar, nicht den Betrieb anonym

Revision 12 wurde am 28. September 2026 als aktiver CFRG-Entwurf im IRTF-Stream eingereicht und zielt auf Informational. Sie ist noch Internet-Draft, kein veröffentlichter RFC, kein Standards-Track-Standard und kein Nachweis für Implementierung, Interoperabilität oder Verbreitung.

Gegenüber Revision 11 ersetzt sie sichtbare Template-Platzhalter durch konkrete Ciphersuite-Konstanten, Skalare, Generatoren, Signaturen und Proof-Fixtures. Implementierer können feste Eingaben ausführen und das Ergebnis bytegenau vergleichen. Für Mathematik, Serialisierung und API-Kompatibilität ist das wertvoll.

Eine Fixture liefert jedoch Schlüssel, Nachrichten, Header und simulierten Zufall. Im Betrieb muss jemand belegen, wer den Schlüssel veröffentlicht hat, ob alle dieselbe Key View erhielten, wie groß die Population hinter einem Header ist, ob ein RNG nach Fork oder Snapshot Zustand wiederholte und welche Identifikatoren Wallet, Transport und Verifier ergänzten. Das Testvektor-Ergebnis sieht diese Entscheidungen nicht.

Die Freigabeakte braucht daher zwei getrennte Spuren. Eine sagt: Dieser Build erzeugt für Revision 12 die erwarteten Bytes. Die andere behandelt Schlüsselverteilung, Kohortengröße, Schemaform, Zufallsquelle, Metadaten und Korrelationstests. Die erste kann die zweite nicht vertreten.

VALID ist ein Satz mit einer scharfen Grenze

BBS signiert eine geordnete Nachrichtenliste mit einer Signatur konstanter Größe. Der Holder erzeugt danach einen randomisierten Kenntnisnachweis und legt eine beliebige Teilmenge offen. Der Verifier erhält öffentlichen Signer-Schlüssel, Proof, signaturgebundenen header, proofgebundenen presentation_header, offengelegte Nachrichten und deren ursprüngliche Indizes.

Bei Erfolg lässt sich sagen: Der Prover kennt unter diesem Schlüssel eine gültige BBS-Signatur; die sichtbaren Werte standen an diesen Positionen; die Header sind in den Proof eingebunden; der Proof verrät weder die verborgene Signatur noch die nicht offengelegten Werte.

Nicht gesagt wird, welche Person die Software steuert, wie der Issuer eine reale Behauptung überprüfte, ob ein Credential widerrufen oder suspendiert wurde, ob etwas Entscheidendes fehlt, welche lokale Policy gilt oder ob eine genehmigte Handlung tatsächlich wirkte.

Die bestehende Berichterstattung zu RFC 9901 besitzt bereits die SD-JWT-Grenze zwischen korrekter Offenlegung und vollständigem Datensatz. Die BBS-Grenze hier ist die Trennung zwischen einem unverknüpfbaren Proof und einem möglicherweise wiedererkennbaren Präsentationsumschlag.

Der Signer-Header kann zu einem dauerhaften Namen werden

Der Entwurf kennt zwei Header mit unterschiedlichen Eigentümern. header wird vom Signer gewählt, an die ursprüngliche Signatur und jeden abgeleiteten Proof gebunden und bei jeder Präsentation sichtbar. Er eignet sich für gemeinsamen Kontext wie Anwendung, Deployment-Domain oder Versionsklasse. Ein individueller Wert wird dagegen zur dauerhaften Marke.

Zufällige Credential-ID, E-Mail-Adresse, Gerätekennung oder sekundengenaue Ablaufzeit wiederholen sich über alle Präsentationen. Die Randomisierung des Proofs hilft gegen diesen einfacheren Join Key nicht. Der Entwurf verlangt deshalb einen niedrig-entropischen Wert, den eine große Population teilt.

Niedrige Entropie ist kontextabhängig. Ein Ländercode kann global Millionen und in einem Sonderprogramm zwei Personen umfassen. Eine verbreitete Version kann nach einem Rollout nur noch drei Altgeräte markieren. Header, Schlüssel, Region und Nachrichtenform können gemeinsam eine Einzelperson isolieren.

Der Issuer-Beleg sollte exakte Bytes, Erzeugungsregel, erwartete und beobachtete Population, zugehörigen Schlüssel und Ausnahmen erfassen. Der Holder kann den signierten Header nicht nachträglich ersetzen. Auswahlmacht und Risikoverantwortung liegen daher beim Issuer.

Der Präsentations-Header bindet einen Challenge, nicht dessen ganze Bedeutung

presentation_header wird für einen einzelnen Proof gewählt. Er kann Verifier-Nonce, Audience, Domain, Gültigkeitszeit oder eine vom Prover signierte Nachricht tragen. Ein gültiger Proof bestätigt Integrität und Bindung dieses Wertes.

Frische ist dennoch externer Zustand. Der Verifier muss wissen, wer den Nonce erzeugte, welcher Sitzung und Audience er gehört, wann er verfällt und ob er bereits verbraucht wurde. Nichtinteraktive Verfahren benötigen eine andere Eindeutigkeitsregel. Ein neuer Wert kann an die falsche Transaktion gebunden sein.

Hohe Entropie ist vertretbar, wenn der Wert pro Proof neu und nicht identifizierend ist. Wiederverwendung schafft einen stabilen Griff. Kontonummer, exakte Position oder seltenes Build können schon bei einmaliger Nutzung identifizieren. Kryptografische Integrität ist keine Datenschutzklassifikation.

Das Log braucht Herkunft, Sitzung, Audience, Erstellung, Ablauf und Verbrauch — mit begrenzter Aufbewahrung. Nur „Nonce gültig“ verhindert Rekonstruktion; ewige Speicherung aller Challenges erzeugt eine neue Tracking-Datenbank.

Auch die Form der Geheimnisse ist Information

Proof-Länge und Offenlegungszahl verraten die Gesamtzahl signierter Nachrichten; Indizes verraten deren Schema-Position. Fünf Felder für Beschäftigte, neun für Auftragnehmer und dreizehn für ein Schutzprogramm reichen zur Klassifikation, ohne einen verborgenen Wert zu lesen.

Eine seltene Indexkombination wird zum Fingerabdruck. Mehrere Verifier können durch Schnittmengen die Gruppe weiter verkleinern. Deshalb empfiehlt der Entwurf gemeinsame Auffülllängen und konsistente Reihenfolge, soweit praktikabel. Das sind Populationskontrollen, keine Formatkosmetik.

Die Evidenz umfasst Schemaversion, Längenverteilung, Padding-Regel, Indexkarte und Tests optionaler Claims. Padding kostet Bytes und Komplexität; eine seltene Padding-Policy kann selbst markieren. Zuerst ist festzulegen, welche Personen ununterscheidbar bleiben sollen; danach wird die kleinste tatsächlich erzeugte Klasse gemessen.

Der öffentliche Schlüssel kann vor dem ersten Proof segmentieren

Jeder Proof wird unter einem Signer-Schlüssel geprüft. Nutzt der Issuer einen Schlüssel nur für eine Person oder kleine Kohorte, weist jeder Proof bereits auf diese Kohorte. Die Proof-Werte müssen dafür nicht miteinander verglichen werden.

Das kann aus regional versetzter Rotation, Canary, Incident-Isolation oder geerbter Hierarchie entstehen. Es kann auch absichtlich sein: ausgewählte Holder erhalten eine abweichende Key View und damit ein unsichtbares Etikett.

„Schlüssel gültig“ ist kein ausreichender Beleg. Nötig sind Schlüsselbytes und ID, Veröffentlichungsweg, Aktivierung, Ausmusterung, geplante und reale Population sowie Konsistenznachweis. Key-Consistency-Verfahren sind ein Ansatz; die Pflicht lautet, selektive Fragmentierung der Sicht auszuschließen.

Ein globaler Schlüssel vergrößert Anonymitätsmenge und Schadensradius. Hierarchische Schlüssel verbessern Isolation und verkleinern Gruppen. Die Organisation muss die zu schützende Population je Schlüssel nennen und nach jeder Rotation messen.

Ein wahrer offengelegter Wert kann der stärkste Identifikator sein

Vollname, amtliche Nummer, Mail oder Telefon können korrekt signiert und bewusst gezeigt werden. Wiederholt verbinden sie Präsentationen direkt. Auch Beruf, kleines Dorf und genaues Geburtsdatum können gemeinsam eindeutig sein.

BBS bestätigt Authentizität, nicht Erforderlichkeit. Zweck, Verhältnismäßigkeit, Aufbewahrung und Alternativen gehören zur Anwendung. Ein Dienst, der für „über 18“ das ganze Geburtsdatum verlangt, vernichtet Datenschutznutzen ohne den Algorithmus zu verletzen.

Range- oder Set-Membership-Proofs können helfen, sind aber eigene Konstruktionen. Basis-BBS macht aus einem Alter keinen Schwellenwert und beweist keine Nichtwiderrufung, nur weil eine Revocation-ID verborgen bleibt.

Zufall ist Bestandteil der Vertraulichkeit

ProofGen benötigt mehrere unabhängige, pro Aufruf einzigartige und gleichverteilte Skalare. Wiederverwendung, Vorhersagbarkeit oder bekannte Beziehungen können verborgene Nachrichten oder Signatur offenlegen. Der Output kann formal korrekt aussehen, obwohl Privacy bereits verloren ist.

Der Text beschreibt auch einen Exfiltrationskanal: Manipulation weniger Zufallsbits kann Daten in scheinbar normalen Proofs tragen. Ein deterministischer Generator mit einmaligem, uniformem Seed kann das in sensiblen Umgebungen begrenzen; sichere Entropie und Seed-Verwahrung bleiben notwendig.

Produktionsbelege benennen RNG, Bibliotheksbuild, Seed-Pfad, Health Tests, Prozess- und Gerätebedeutung, Fork, Snapshot-Restore und Fehlerreaktion. „System-RNG“ ist Architekturbehauptung, kein Laufzeitbeleg.

Schlüsseldeserialisierung, Subgroup Checks, Domain Separation, Side-Channel-Schutz und einheitliches Message-to-Scalar-Preprocessing bleiben eigenständige Kontrollen. Ein bestandener Vektor beweist sie nicht automatisch.

Benachbarte Erweiterungen nicht in Basis-BBS hineinlesen

Blind BBS Signatures ist ein separates Protokoll, mit dem der Signer über Holder-Nachrichten signiert, die durch Commitment verborgen sind. Basis-Offenlegung versteckt bei Präsentation vor dem Verifier; sie beweist keine Blindheit des Issuers bei Ausstellung.

BBS per Verifier Linkability ergänzt ein kontextgebundenes Pseudonym. Ein Verifier kann Rückkehr erkennen, während verschiedene Kontexte unverknüpfbar bleiben sollen. Basis-BBS erzeugt dieses stabile Pseudonym nicht von selbst.

W3C bbs-2023 ist ein Verifiable-Credentials-Profil mit Mandatory/Selective Pointers, Transformation und optionalem Holder Binding oder Pseudonym. Beschaffung muss Revision, Ciphersuite, Interface, Erweiterung und Profil einzeln benennen. „BBS unterstützt“ ist keine Kompatibilitätsmatrix.

Quantenrisiko trennt Authentizität und Geheimhaltung

BBS-Authentizität hängt am diskreten Logarithmus und ist nicht postquantenfest. Ein kryptografisch relevanter Quantencomputer könnte den Signer-Secret ableiten, Signaturen fälschen und daraus gültige Proofs erzeugen.

Der Entwurf trennt davon die Vertraulichkeit bereits erzeugter Proofs. Das Verbergen nicht offengelegter Nachrichten und der Signatur ist informationstheoretisch; selbst unbegrenzte Rechenleistung mit Signer-Secret extrahiert sie nicht aus dem Proof. Das ist Everlasting Privacy des Proofs, kein Quantum-Safe-Label für das Gesamtsystem.

Migration braucht zwei Uhren. Authentizität muss vor der relevanten Bedrohung ersetzt werden. Alte Transcripts können weiterhin verbergen, während Header, sichtbare Werte, IPs und Logs korrelierbar bleiben. Schlüsselrotation löscht keine Kopie.

Der Beleg muss die ganze Interaktion erfassen

Die Mindestkette trennt Dokumentversion und Ciphersuite; Schlüsselherkunft und View-Konsistenz; blinde oder gewöhnliche Ausstellung; Header und Kohortengröße; Schema, Reihenfolge und Padding; Werte und Indizes; presentation header, Nonce, Audience und Frische; Proof und Urteil; RNG; Parser, Subgruppe und Domain Separation; Netzwerk- und Gerätemetadaten; Status/Widerruf; Policy; Berechtigung; Aktion; Wirkung; Aufbewahrung; Migration.

Nicht alles gehört in eine Zentrale. Issuer, Wallet, Verifier, Anwendung, Security und Privacy bewahren die Entscheidung auf, die sie kontrollieren, und verbinden sie über begrenzte Transaktionsidentität. Lu Hengs Minimum Initial Specification hält den gemeinsamen Mechanismus klein. Reality Layers verhindern, dass Zero Knowledge die Autorität einer Berechtigung übernimmt. Running-Code Primacy fragt, welcher Schlüssel, welches Schema, welcher RNG, welches Binary und welcher Log-Pfad tatsächlich liefen.

BBS verspricht nicht zu wenig. Es verspricht etwas Starkes über einen genau bezeichneten Gegenstand. Der Fehler beginnt, wenn „das ganze System“ ohne neue Belege angehängt wird.

Quellen