Warum geht keine Sicherheit verloren, wenn in Schnorr-Signaturen 32-Byte-öffentliche Schlüssel anstelle von 33 verwendet werden?

Auf der Mailingliste wird derzeit darüber diskutiert, das 33. Byte von öffentlichen Schlüsseln bei der Verwendung in bip-schnorr abzuschneiden.

Öffentliche Schlüssel sind (x, y)Koordinaten, und komprimierte öffentliche Schlüssel ersetzen einfach die yKoordinate durch ein einzelnes Byte, das ihre Ungeradheit anzeigt. Aus der gegebenen Koordinate lässt sich dann die vollständige yKoordinate ableiten x, sodass der öffentliche Schlüssel in nur 33 statt 64 Bytes ausgedrückt werden kann.

Durch das Entfernen des „Oddness“-Bytes werden öffentliche Schlüssel nur durch die Koordinate ausgedrückt x, was bedeutet, dass es zwei potenzielle Punkte auf der Kurve gibt, die dargestellt werden könnten. Dies impliziert auch, dass derselbe öffentliche Schlüssel nur mit x-Koordinate tatsächlich von zwei verschiedenen privaten Schlüsseln abgeleitet werden könnte.

Meine Frage ist, warum wirkt sich dies nicht auf die Sicherheitsannahmen der Schnorr-Signatur aus? Ist es nur ein subtiler Effekt, wie das Ersetzen von 256-Bit-Sicherheit durch 255-Bit-Sicherheit?

Antworten (2)

Aus dem (sehr kürzlich aktualisierten) bip-schnorr- Entwurf:

Implizite Y-Koordinaten stellen keine Verringerung der Sicherheit dar, wenn sie als Anzahl von Elliptische-Kurven-Operationen ausgedrückt werden, die ein Angreifer voraussichtlich ausführen wird, um den geheimen Schlüssel zu berechnen. Ein Angreifer kann jeden gegebenen öffentlichen Schlüssel auf einen Punkt normalisieren, dessen Y-Koordinate ein quadratisches Residuum ist, indem er den Punkt bei Bedarf negiert. Dies ist nur eine Subtraktion von Feldelementen und keine Elliptische-Kurven-Operation.

Die Idee ist, dass, wenn die Verwendung impliziter Y-Koordinaten irgendwie weniger sicher wäre, ein Angreifer sie immer verwenden würde – selbst in einer Protokollversion mit expliziten Y-Koordinaten. Der Angreifer würde den vollständigen öffentlichen Schlüssel nehmen, die Y-Koordinate entfernen, seinen (vermutlich schnelleren) impliziten Y-ECDLP-Löser darauf ausführen, um den privaten Schlüssel zu finden, und wenn der tatsächliche Punkt, der diesem Schlüssel entspricht, das Gegenteil von dem ist, was er will, Drehen Sie den privaten Schlüssel um.

Dies beweist, dass die Härte des ECDLP-Problems nicht sinnvoll durch Entfernen der Y-Koordinaten beeinflusst werden kann.

Dieser Artikel erweitert den Sicherheitsnachweis etwas mehr (mit visuellen Hilfsmitteln!)

https://medium.com/blockstream/reducing-bitcoin-transaction-sizes-with-x-only-pubkeys-f86476af05d7