Was sind die Auswirkungen von Schnorr-Signaturen?

Warnung: Ich habe noch nie mit dem Schnorr-Signaturschema gearbeitet. Das Folgende ist meine Analyse, die auf dem Lesen des Wikipedia-Artikels , der Seite ed25519 und einigen Diskussionen zwischen Entwicklern in #bitcoin-dev basiert .

Wahrscheinliche Änderungen

1. Geändertes Opcode-Verhalten: Wir benötigen einen Opcode, um Schnorr-Signaturen zu überprüfen. Mit einem Hard Fork können wir Schnorr-Signaturen neu definieren op_checksigund op_checksigverifyauch überprüfen. Mit einem Soft Fork können wir einen der reservierten No-Op-Op-Codes neu definieren , um Schnorr-Signaturen zu prüfen.

2. Erhöhte P2SH-Nutzung (vielleicht): Ich denke, es ist höchst unwahrscheinlich, dass ein neues Adressformat eingeführt wird, das für Pubkey-Skripte, die öffentliche Schnorr-Schlüssel bezahlen, dasselbe tut wie P2PKH für öffentliche ECDSA-Schlüssel. Das bedeutet, dass Personen, die eine Adresse für die Verwendung von Schnorr auch mit nur einem Schlüssel (nicht Multisig) benötigen, P2SH verwenden müssen. Natürlich können sie für Anwendungen, die keine Adressen benötigen (wie zum Mining oder bei Verwendung des BIP70- Zahlungsprotokolls), einfach op_checksigverify_schnorr(oder was auch immer) direkt in ihren Pubkey-Skripten verwenden .

3. Kleinere Multisig-Transaktionen: Einer der am häufigsten angepriesenen Vorteile des Schnorr-Schemas besteht darin, dass es mehreren Unterzeichnern ermöglichen kann, ihre Signaturen zu einer einzigen Signatur zu kombinieren, die gegen einen einzigen öffentlichen Schlüssel authentifiziert werden kann, der von allen autorisierten Parteien erstellt wurde. Dies erreicht dasselbe wie das aktuelle Bitcoin-Multisig, verwendet jedoch weniger Bytes. Dies kann besonders nützlich sein, wenn Dutzende oder Hunderte von Unterschriften erforderlich sind, beispielsweise in einer Crowdfunding-Situation. Hinweis: Wenn ich das richtig verstehe, ist dies auch mit ECDSA möglich, jedoch weniger flexibel. (Anmerkung von 2018: Es gibt jetzt ein Papier, das beschreibt, wie man scriptlose Skripte auf ECDSA macht , einschließlich 2-von-2-Multisig)

4. Etwas kleiner für alle Transaktionen: Unter der Annahme, dass Bitcoin die ed25519- Kurve verwendet, die eine ähnliche Schlüsselstärke wie die secp256k1- ECDSA-Kurve hat, die Bitcoin derzeit verwendet, werden komprimierte öffentliche Schnorr-Schlüssel und -Signaturen (jeweils) 32 Bytes und bis zu 64 Bytes im Vergleich zu aktuell komprimiert sein Bitcoin secp256k1 öffentliche Schlüssel und (nicht komprimierte) Signaturen, die 33 Byte und bis zu 75 Byte groß sind.

5. Plausible Leugnung für Multisig: Mit Schnorr - Schwellensignaturen kann es einfacher sein, zu verhindern, dass mehrere Unterzeichner oder Dritte wissen, wer sonst noch unterschrieben oder nicht unterschrieben hat. Das liegt daran, dass die einzelnen Signaturen zu einer einheitlichen Signatur zusammengeführt werden, die nicht direkt verrät, wer sie signiert hat. Dies kann in Situationen verwendet werden, in denen die Unterzeichner Angst vor Repressalien haben, wenn sie Gelder auf eine bestimmte Weise ausgeben.

6. Plausible Bestreitbarkeit von BerechtigtenDurch die Verwendung eines Drittanbieter-Organizers (dem private Schlüssel nicht anvertraut werden müssen) ist es möglich, zu verhindern, dass Unterzeichner wissen, ob ihr privater Schlüssel Teil des Satzes von Signaturschlüsseln ist. Obwohl nicht direkt relevant für Bitcoin-Transaktionen, erinnere ich mich [1] an Greg Maxwell, der sagte, er würde gerne sehen, dass diese Eigenschaft für die verteilte Forenmoderation verwendet wird: Wählen Sie eine Gruppe hochrangiger Forumsmitglieder aus, erhalten Sie einen öffentlichen Schlüssel von jedem von ihnen, erstellen Sie einen öffentlichen Schwellwertschlüssel von einigen der individuellen öffentlichen Schlüssel, und lassen Sie dann Einzelpersonen eine Unterschrift senden, wenn sie der Meinung sind, dass ein Beitrag entfernt werden sollte. Der Drittanbieter-Organisator (wahrscheinlich ein automatisiertes Programm) wird die Signaturen kombinieren, ohne dass deren Signatur tatsächlich zum Erreichen des Schwellenwerts beigetragen hat. Wenn niemand weiß, wessen Unterschrift tatsächlich zählt und der Pool an möglichen Moderatoren groß ist, werden wirksame Repressalien gegen Moderatoren sehr teuer. [1]: #bitcoin IRC vor etwa 4 Monaten; Leider ist dieser Chatroom nicht öffentlich angemeldet.

7. Theoretisch bessere Sicherheitseigenschaften: Die Experten sind sich einig, dass allgemeine Schnorr-Signaturen bessere theoretische Sicherheitseigenschaften haben als entsprechende ECDSA-Signaturen. Die bemerkenswerteste dieser Verbesserungen ist, dass die in Schnorr verwendete Hash-Funktion nicht so kollisionsfest sein muss wie die in ECDSA verwendete Hash-Funktion. (Bitcoin würde wahrscheinlich die gleiche Hash-Funktion für Schnorr verwenden, die es für ECDSA verwendet: SHA256.) Außerdem beschreibt die oben verlinkte ed25519-Seite mehrere Möglichkeiten, wie es gegen Seitenkanalangriffe resistent ist, wodurch Hardware-Wallets in weniger sicheren Fällen sicher arbeiten können Umgebungen.

8. Schnellere Signaturüberprüfung: Es dauert wahrscheinlich weniger CPU-Zyklen, um eine ed25519-Schnorr-Signatur zu überprüfen als eine secp256k1-ECDSA-Signatur. Dies ist wahrscheinlich nur eine winzige Verbesserung für Bitcoin: Bitcoin Core überprüft Signaturen, bevor es eine Transaktion zu seinem Mempool hinzufügt. Wenn ein Block empfangen wird, der bereits Transaktionen im lokalen Mempol enthält, überprüft Bitcoin Core diese Transaktionen nicht erneut, so dass, solange der lokale Knoten und der Mining-Knoten identische Mempools haben, keine Signaturüberprüfungen durchgeführt werden müssen. (Erinnern Sie sich, dass die Coinbase-Transaktion keine Signatur hat.) Die Signaturüberprüfung ist jedoch derzeit ein einschränkender Faktor für Knoten während des anfänglichen Blockchain-Downloads (unter der Annahme einer Hochgeschwindigkeitsverbindung und Bitcoin Core 0.10.0), also „schneller wäre besser. "

9. Multi-Krypto-Multisig: Mit zwei (leicht) unterschiedlichen Kryptosystemen zur Auswahl können Hochsicherheitsbenutzer 2-von-2-Multisig-Pubkey-Skripte erstellen, die sowohl ECDSA- als auch Schnorr-Signaturen erfordern, sodass ihre Bitcoins nicht gestohlen werden können, wenn nur ein Kryptosystem vorhanden ist ist kaputt. Wenn wir in Schnorr kein Hardfork durchführen (siehe Punkt 1), können sie den Standard op_checkmultisig nicht verwenden – aber sie können so etwas tun<ecdsa pubkey> OP_CHECKSIGVERIFY <schnorr pubkey> OP_CHECKSIGVERIFY_SCHNORR

Unsicherheiten (für mich)

10. Vielleicht geänderte TXIDs: Ich bin mit Schnorr-Signaturen nicht vertraut genug, um zu wissen, wie sie veränderbar sein könnten (von Dritten veränderbar, ohne sie ungültig zu machen), aber der Krypto-Experte Adam Back scheint zu glauben, dass sie ziemlich veränderbar wären. Seine Lösung wäre, die Berechnung von TXIDshash(<whole transaction>) von auf zu ändern hash(<almost everything except the signature>). Dies würde einige aktuelle Probleme auf der Grundlage der Formbarkeit beheben, wie z. B. die langsame Erstellung von Mikrozahlungskanälen , aber es wäre auch ein wichtiger Hard Fork, der effektiv die gesamte Bitcoin-Software betrifft. Der letzte Fork dieser Größenordnung – die Soft-Fork- P2SH-Implementierung--- wird nach drei Jahren Diskussion, zwei Jahren Implementierung und ziemlich weit verbreiteter Nutzung immer noch nicht von allen Bitcoin-Programmen unterstützt.

• Wiederherstellung öffentlicher Schlüssel aus Signaturen: Ich weiß nicht, ob ein öffentlicher Schnorr-Schlüssel aus einer Schnorr-Signatur so wiederhergestellt werden kann, wie ein ECDSA-Pubkey aus einer ECDSA-Signatur wiederhergestellt werden kann. Dies könnte wichtig sein: Der Bitcoin Core verifymessageRPC verwendet die Schlüsselwiederherstellung, um Nachrichten zu verifizieren, die mit dem signmessageRPC oder durch die Signierungsnachrichtenimplementierung eines anderen Clients signiert wurden. (Hinweis: Dieser Punkt wurde nicht nummeriert, da er nach dem ursprünglichen Beitrag hinzugefügt wurde.)

Nicht-Änderungen

Nur um das klarzustellen, hier sind einige Dinge, die sich nicht ändern.

11. Deterministische Signaturen: Es gab einen Trend zu deterministischen ECDSA-Signaturen in Bitcoin-Software. Beispielsweise wird Bitcoin Core sie in der kommenden Version 0.10.0 verwenden. Schnorr-Signaturen können auch deterministisch generiert werden. Bei deterministischen Signaturen benötigen Sie keine hochwertige Entropiequelle (Zufälligkeit), um sichere Signaturen zu erstellen. Sie benötigen jedoch immer noch qualitativ hochwertige Entropie, um private Schlüssel oder Root-Seeds zu generieren (siehe Punkt unten).

12. HD-Geldbörsen: Für mich sieht es so aus, als würde das hierarchische deterministische (HD) Schlüsselgenerierungsprotokoll mit ein paar kleinen Änderungen für Schnorr-Schlüsselpaare funktionieren. Sie können sogar denselben Root-Seed für ECDSA- und Schnorr-Hierarchien verwenden.

13. Wiederverwendung von Schlüsseln (Adressen): Wie bei richtig implementiertem ECDSA ist es möglich, mehrere Schnorr-Signaturen für verschiedene Transaktionen sicher zu erstellen, was bedeutet, dass es sicher ist, mehrere Ausgaben an dieselbe Adresse oder denselben öffentlichen Schlüssel zu erhalten. Dies steht im Gegensatz zu einigen Signaturschemata, bei denen Sie nur eine Signatur pro öffentlichem Schlüssel sicher verwenden können. Die Wiederverwendung von Schlüsseln kann jedoch immer noch weniger sicher sein als die Verwendung eindeutiger Schlüssel für jede Transaktion, und die Wiederverwendung von Schlüsseln ist für Sie und Ihre Handelspartner immer viel weniger privat.

Priorität

Nur meiner Meinung nach: Schnorr scheint einige nette Vorteile gegenüber ECDSA für Power-User zu bieten, aber niemand scheint um diese Funktionen zu betteln - also hat das Hinzufügen von Schnorr-Signaturen wahrscheinlich niedrige Priorität. Ich würde vermuten, dass die Unterstützung der Schnorr-Signatur eine der ersten Verbesserungen sein könnte, die in einer Sidechain (PDF-Link) vollständig getestet wird, bevor sie zurück auf Bitcoin portiert wird.

PS Entschuldigung für den langen Beitrag, aber danke, dass du so eine lustige Frage gestellt hast!

Ja, Sie können öffentliche Schlüssel mit EC Schnorr wiederherstellen. In Betracht ziehen

R = kG, [r = R.x, s = k + H(r, m)d], Q = dG

verifizieren:

sG = ?R + H(r, m)Q

Wiederherstellung:

sG = kG + H(r, m) dG = R + H(r, m)Q

Also

Q = 1 / H(r, m) * (sG - R).

(Und um zu berechnen R, rob Res punktkomprimiert ist, R = (r,f(r)) R' = (r,-f(r))und versuchen Sie sowohl Rals auch R', indem Sie mit dem resultierenden öffentlichen Schlüssel prüfen, ob die Signatur gültig ist).

Das primäre Designziel für DSA war es, eine Verletzung des Schnorr-Patents zu vermeiden. Jetzt, da das Patent abgelaufen ist, gibt es keine wirklich guten mathematischen Gründe, sich für DSA zu entscheiden. Mit Schnorr sind der Algorithmus und die Analyse einfacher und oft effizienter. Es ist auch einfacher, private Schnorr-Schlüssel zu teilen, Schwellwertvarianten zu erstellen usw. DSA und ECDSA sind jedoch Standards, und das schon seit einiger Zeit. Folglich sind Bibliotheksimplementierungen überall. Sie können Unterstützung für Hardware-Sicherheitsmodule usw. finden. Eines Tages wird dasselbe entweder für Ed25519 oder eine andere Schnorr-Variante gelten. Es ist unwahrscheinlich, dass neue DSA-Varianten standardisiert werden. Aber im Moment ist ECDSA immer noch der Algorithmus, den Sie verwenden sollten, wenn Sie etwas Standardisiertes und weithin Unterstütztes wollen.