Gibt es Risiken bei der Verwendung desselben privaten Schlüssels für ECDSA- und Schnorr-Signaturen?

Ich glaube, ich habe einen Kommentar von Greg Maxwell dazu gesehen, aber ich habe Probleme, ihn zu finden. Ich denke, es gab ein gewisses Risiko, wenn dieselbe Nachricht mit demselben Schlüssel mit beiden Algorithmen signiert wurde?

In dieser verwandten Frage sehe ich, dass ECDSA-Signaturausgaben, (h, s)aber Schnorr-Ausgaben (r, s). In ECDSA rwird also ein geheimer Wert aufbewahrt, aber er wird in Schnorr offenbart – macht das den privaten Schlüssel irgendwie wiederherstellbar?

Ich denke, OP bezieht sich auf diese Mail auf der bitcoin-dev-Mailingliste

Antworten (1)

Kopieren der Zusammenfassung aus meinem Mailinglisten- Post zu diesem Thema:

  • Um im Bereich der nachweisbaren Sicherheit zu bleiben, ist es ratsam sicherzustellen, dass ECDSA-Schlüssel und Schnorr-Schlüssel unterschiedliche gehärtete Ableitungsschritte verwenden.
  • Selbst wenn Sie dies nicht tun, sind Sie wirklich nur wieder auf dem Sicherheitsniveau, das wir über ungehärtete BIP32-ECDSA-Schlüssel hatten, bevor ein Beweis bekannt wurde (was den meisten Menschen meiner Meinung nach nicht einmal bewusst ist).

Es sind keine Angriffe gegen die Wiederverwendung von Schlüsseln in ECDSA und Schnorr bekannt (zumindest solange die Nonces nicht zusammenhängend/unvorhersehbar sind, aber wenn dies nicht der Fall ist, haben Sie auch ein Problem mit der Wiederverwendung innerhalb von ECDSA oder innerhalb von Schnorr).

Es gibt aber auch keinen Sicherheitsnachweis für die Wiederverwendung quer, soweit ich weiß, aber das ist nicht wirklich schlimmer als die Situation für ECDSA allein bis vor kurzem.

Ich sollte jedoch hinzufügen, dass die Verwendung desselben deterministischen Nonce-Schemas (z. B. rfc6979) über ECDSA und Schnorr hinweg und das Signieren derselben Nachricht mit beiden den Schlüssel verlieren!
Das ist wahr, aber kein Risiko im aktuellen Transaktionssignaturschema, da die Nachricht garantiert für beide unterschiedlich ist (Hash wird unterschiedlich berechnet und Hash-Commits für die Ausgabe von bwing ausgegeben, die indirekt an das Skript übergeben wird).