Zusammenfassung

  • RFC 9591 lässt eine Schwellenmenge in zwei Runden Anteile erzeugen, die zu einer unter dem Gruppen-Public-Key prüfbaren Schnorr-Signatur (R, z) aggregiert werden.
  • Die Ausgabe enthält weder Teilnehmerliste noch Einzelanteile oder Geschäftsfreigaben. Dafür braucht die Anwendung einen authentisierten, versionierten Sitzungsnachweis.

Der Empfänger sieht absichtlich nur die Gruppe

Bei einem Drei-von-fünf-System kann jede zulässige Dreiergruppe eine Signatur beisteuern. Die endgültige Prüfung belegt, dass Nachricht, Signatur und Gruppen-Public-Key mathematisch zusammenpassen. Sie zeigt nicht, welche Kombination beteiligt war. Ebenso wenig zeigt sie, ob die Beteiligten denselben Auftrag gelesen oder nur einen fremd erzeugten Hash verarbeitet haben.

Diese Reduktion ist ein Vorteil. Einige FROST-Ciphersuites erzeugen Signaturen, die mit Ed25519- oder Ed448-Prüfern kompatibel sind. Der Empfänger muss das verteilte Innenleben nicht kennen. Geheimnisverwahrung kann verteilt werden, ohne jedes abhängige Protokoll umzubauen.

Gerade deshalb darf eine Oberfläche „Gruppensignatur gültig“ nicht in „benannte Instanz hat genehmigt“ umdeuten. Der erste Satz beschreibt eine kryptografische Relation. Der zweite braucht Mandat, Identität und Anwendungsregeln.

Die konkrete Runde wird außerhalb von FROST zusammengesetzt

Teilnehmer besitzen eindeutige skalare Kennungen, geheime Schlüsselanteile und öffentliche Prüfanteile. Hinzu kommen Gruppen-Public-Key, Mindestschwelle und Maximalpopulation. Für eine Ausführung wählt der Koordinator die Teilnehmer, vermittelt beide Runden, aggregiert und veröffentlicht.

RFC 9591 stellt klar, dass Koordinator und Signierermenge extern gewählt werden. Eine Variante ohne einzelnen Koordinator verteilt die Kommunikation auf alle. Doch auch dort muss eine Anwendung Berechtigung, Schwelle, Nachricht, Frist und Freigabebedingung festlegen.

Die skalare Kennung ist kein Personal- oder Vollmachtsnachweis. Ihre Bindung an Person, Dienst, Rolle und Gültigkeitszeitraum braucht ein separates Register. Ein Rollenwechsel widerruft einen kryptografischen Anteil nicht automatisch.

Einmalige Nonces machen Wiederherstellung zu einer Sicherheitsfrage

In Runde eins erzeugt jeder Teilnehmer zwei geheime Nonces und deren öffentliche Commitments. Runde zwei liefert Nachricht und vollständige, sortierte Commitment-Liste. Gruppen-Public-Key, Nachricht, Liste und Teilnehmerkennung bestimmen Bindungsfaktoren; anschließend entsteht der Signaturanteil.

Die Nonces dürfen nur einmal in sign eingehen und müssen danach gelöscht werden. Wiederverwendung kann den vollständigen geheimen Anteil offenlegen. Ein Hochverfügbarkeitskonzept, das nach einem Rollback alten Nonce-Zustand erneut anbietet, kann somit Verfügbarkeit wiederherstellen und zugleich die Schlüsselkontrolle zerstören.

Auch die Kontinuität der Teilnehmermenge ist ein Sicherheitsbeleg. Der RFC empfiehlt eine schnellere Optimierung nicht, weil sie nicht mehr garantiert, dass die Starter von Runde eins dieselben sind wie die Produzenten in Runde zwei. Ein Benchmark ohne diesen verlorenen Beleg ist unvollständig.

Aggregation entfernt die spätere Prüfspur

Der Koordinator addiert Anteile zu R und z. Im kanonischen Ergebnis stehen keine Teilnehmerkennungen, Commitments, Einzelanteile, Schwelle oder lokalen Freigaben. Eine nachträgliche Analyse der gültigen Signatur kann diese Daten nicht rekonstruieren.

Vorher lässt sich jeder Anteil anhand von öffentlichem Teilnehmeranteil, individuellen Commitments, Gesamtliste, Nachricht und Gruppenschlüssel prüfen. Bei einem Fehler kann dies den mathematischen Teilnehmer benennen. Für eine zurechenbare Quelle ist zusätzlich ein authentisierter Kanal nötig.

Nichtteilnahme ist etwas anderes. FROST erkennt nicht von selbst, wer eine Anfrage absichtlich verweigert. Die Anwendung kann Zustellung, Frist und fehlende Antwort beobachten. Daraus folgen noch keine Aussagen über Motivation, Kompromittierung oder Pflichtverletzung. Sanktionen und Ausschluss liegen außerhalb des RFC.

Ein korrekter Anteil ist keine Sachfreigabe

RFC 9591 empfiehlt anwendungsspezifische Eingabeprüfung, damit Teilnehmer nicht zu Signierorakeln werden. Eine Transaktion kann Syntax, Ziel und Willen der Betroffenen erfordern. Bei TLS kann der Teilnehmer die rohen Handshake-Nachrichten verlangen, statt einem gelieferten Transcript-Hash blind zu vertrauen.

Ein gültiger Anteil belegt die Berechnung des Schlüsselanteils über die Protokolldaten. Er belegt nicht, dass Benutzeroberfläche, kanonisches Objekt, signierte Bytes und spätere Ausführung übereinstimmen. Auch aktuelle Rolle, Vier-Augen-Regel und Interessenkonflikt sind keine Eigenschaften der Schnorr-Gleichung.

Der Nachweis muss daher Objektfingerabdruck, Signiernachricht, Richtlinienversion, Entscheidung, Identität, Anteilprüfung, Aggregation, Veröffentlichung und Folgewirkung verbinden. Ein einziges Feld „approved=true“ verliert diese Trennlinien.

Identifizierbarer Abbruch ist keine Robustheit

Ein fehlerhafter Anteil oder ein schweigender Teilnehmer kann die Runde blockieren. RFC 9591 sagt ausdrücklich, dass FROST keine Robustheit bereitstellt. ROAST ist ein gesondertes Wrapper-Protokoll für robustere asynchrone Abläufe. FROST ist außerdem nicht quantensicher, sondern beruht auf dem diskreten Logarithmusproblem.

Der Text ist ein Informational RFC aus der IRTF und bildet CFRG-Konsens ab. Er ist kein IETF-Standard und keine Einführungspflicht. Testvektoren und Bibliotheksunterstützung beweisen nicht Mitgliederregister, Kanal, Nonce-Speicher, Richtlinie oder Produktionsarchiv.

Lu Hengs Running-Code-Perspektive verlangt, dass Aussagen bei der tatsächlich ausgeführten Prüfung enden. Die gültige Signatur ist ausführbare Realität. Institutionelle Genehmigung ist eine zusätzliche Autoritätsbehauptung, die einen nachweisbaren Auftrag braucht.

Quellen