Kann R/r in Musig nur von Seeds und Nachrichten-Hashes abgeleitet werden?

Ich frage mich, ob die ersten beiden Roundtrips des Pre-Commiting und des anschließenden Aufdeckens von R/R in der MuSig-Signierung in die Keygen-Phase verschoben und deterministisch gemacht werden können. Das reduziert die Menge der auszutauschenden Nachrichten; Da Keygen nur einmal durchgeführt wird, möchten wir diese Phase erweitern. Dies wäre besonders nützlich für HD-Wallets: Auf Kosten der komplizierteren Erstellung von Wallets würde das Signieren weniger Interaktionen erfordern.

Das Notenpapier auf Seite 10-11 gibt Folgendes an (aus Sicht des Unterzeichners 1):

MuSig-Schema

Schlüsselgenerierung

  1. generiert den privaten Schlüssel x 1 und den entsprechenden öffentlichen Schlüssel x 1
  2. sendet X 1
  3. erhält X i

Unterzeichnung (insbesondere der Teil über die Vereinbarung von R i )

  1. sendet t 1 =H com (R 1 )
  2. erhält t i
  3. sendet R 1
  4. erhält R i
  5. prüft, ob H com (R i )==t i

r 1 ist als zufällig spezifiziert. Das Signieren umfasst drei Interaktionsrunden, von denen zwei für die obigen Schritte verwendet werden (Einigung auf R i ). Ich möchte diese Schritte in die Keygen-Phase verschieben.

Ein HD-Wallet würde vermutlich BIP32 verwenden, um X 1 zu generieren . Können wir BIP32 auch zum Ableiten von R i /r i verwenden ?

Betrachten Sie stattdessen das folgende Schema. (aus Sicht der Mitunterzeichner 1)

Vorgeschlagenes HD-Schema

HD-Wallet-Setup-Phase

  1. erzeugt xprv y 1 und entsprechendes xpub Y 1
  2. erzeugt xprv k 1 und entsprechendes xpub K 1
  3. sendet xpub Y 1
  4. sendet u 1 =H(K 1 )
  5. empfängt xpub Y i
  6. erhält u i
  7. sendet xpub K 1
  8. erhält xpub K i
  9. prüft, ob H(K i )==u i

Schlüsselgenerierung

  1. von xprv y 1 entlang eines BIP32-Pfades p den privaten Schlüssel x 1 und den öffentlichen Schlüssel X 1 ableiten
  2. von xpub Y i entlang demselben BIP32-Pfad p öffentlichen Schlüssel X i ableiten
  3. von xprv K 1 entlang demselben BIP32-Pfad p, leite den privaten Schlüssel j 1 und den öffentlichen Schlüssel J 1 ab
  4. leite von xpub K i entlang demselben BIP32-Pfad p den öffentlichen Schlüssel J i ab .

Unterzeichnung (insbesondere der Teil über die Vereinbarung von R i )

  1. berechne r 1 =j 1 +hash(m) und R 1 =J 1 +hash(m)*G
  2. berechne R i = J i + hash(m)*G

Dieser Ansatz hat nur eine Interaktionsrunde während des Signierens (Senden von s i , weggelassen, da es sich nicht von dem, was in dem Papier beschrieben ist, geändert hat).

Ich habe den Abschnitt zur Derandomisierung gelesen, aber die Erklärung dafür, warum es nicht funktioniert, erfordert, dass R i vom Angreifer ausgewählt wird. Wenn wir es deterministisch herleiten und BIP32 sicher ist, dann gilt dieser Angriff nicht. In dem Papier heißt es: "Jeder Unterzeichner muss sicherstellen, dass sich sein r i -Wert unvorhersehbar ändert, wenn sich ein von anderen Mitunterzeichnern gesendetes R j oder die Nachricht m ändert. Solange f deterministisch ist, impliziert dies eine kreisförmige Abhängigkeit bei der Auswahl von Zufallswerten."

Wo ist diese zirkuläre Abhängigkeit? Das f aus RFC 6979 hängt nur von key und m ab.

Ich kann das Zusammenspiel mit Musig nicht kommentieren, aber ich werde meine Intuition hier in einem Kommentar hinzufügen. Wenn nach Ihrem Entwurf die Nonce der Signatur vom Unterzeichner über die Ableitung des öffentlichen Schlüssels ausgewählt wird und dies einer anderen Partei offengelegt wird, die den öffentlich ableitbaren Pfad zwischen dem privaten Schlüssel und der Nonce erfährt, dann haben sie jetzt eine Funktion der Nonce als die Öffentlicher Schlüssel. Dies wird höchstwahrscheinlich den privaten Schlüssel preisgeben, wenn eine gültige Signatur über einer Nachricht vom Unterzeichner veröffentlicht wird.
Die zirkuläre Abhängigkeit tritt nur auf, wenn mehrere Parteien vorhanden sind. Damit ein deterministischer Algorithmus sicher ist, muss die Nonce jeder Partei von jeder anderen Nonce abhängen (denn solange sich die Nonce von irgendjemandem zwischen zwei Läufen ändert, muss Ihre auch - oder Sie geben Ihre privaten Schlüssel preis). Sie können nicht k1=F(x1,m,k2*G) und gleichzeitig k2=F(x2,m,k1*G) haben.
Diese zirkuläre Abhängigkeit tritt nur auf, wenn die Nonce nicht nachweisbar deterministisch ist. Wenn jeder in der Lage wäre, allen anderen zu beweisen, dass seine Nonce nur aus seinem privaten Schlüssel, der Nachricht und dem öffentlichen Schlüssel aller berechnet wurde, gäbe es auch kein Problem. Die zirkuläre Abhängigkeit besteht nur, wenn eine Partei einen anderen Algorithmus verwenden könnte.

Antworten (1)

Die Konstruktion, die Sie vorschlagen, wird wahrscheinlich funktionieren, solange Sie nicht mehr als eine Nachricht signieren. Indem Sie die R-Punkte effektiv im Voraus auswählen, haben Sie eine Single-Show-Signatur erstellt.

Die Ableitung, die Sie für die verschiedenen R-Werte verwenden, ist jedoch sinnlos. Es reicht nicht aus, dass Sie R-Werte nicht wiederverwenden; Sie können auch nicht mehrere verwandte R-Werte verwenden. Alle R-Werte, die Sie konstruieren, sind durch eine einzige lineare Gleichung miteinander verbunden. Das reicht einem Angreifer (der den Zusammenhang kennt) aus, um den privaten Schlüssel aus zwei Signaturen abzuleiten.

Technisch lineare Beziehungen können in Ordnung sein, solange es mehr Unbekannte als Gleichungen gibt. Wenn Sie sich beispielsweise auf ein 3000-Grad-Polynom einigen, können Sie Nachrichten-Hashes verwenden, um Orte zum Interpolieren auszuwählen, und bis zu 2999 Signaturen erstellen. Aber kritisch ist, dass all diese Dinge SUPER schwer richtig zu machen und super schwer zu überprüfen sind. Die meisten kryptografischen Konstruktionen sind gebrochen. Ich würde wirklich jeden davor warnen, mit diesem Zeug zu schlau zu sein.
Kann R/r in Musig nur von Seeds und Nachrichten-Hashes abgeleitet werden?
AntwortenHierDatenschutz-Bestimmungen1y, 0v