ECDSA r, s-Kodierung als Signatur

Ein ECDSA-Algorithmus erzeugt beim Signieren einer gegebenen Nachricht ein Paar Ausgaben, r und s . Wie kann man bei einem gegebenen sigStr aus einem Tx r und s extrahieren? Sind sie nur verkettete Byte-Arrays einer bestimmten Länge, oder steckt mehr dahinter?

Antworten (2)

Wenn Sie möchten, können Sie 100 US-Dollar für den Standard ANSI X9.62 bezahlen . Oder Sie können schummeln und sich RFC3278, Abschnitt 8.2 ansehen . Es ist im DER-Format und besteht aus einer SEQUENCE von zwei GANZZAHLEN. Die erste INTEGER ist r, die zweite s.

Wenn Sie sich diese Transaktion ansehen , können Sie sehen, dass eine der Signaturen lautet:

3045 0220
316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d
022100
bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37ae722342b8696

Wenn wir das als DER analysieren, erhalten wir:

 0:d=0  hl=2 l= 69 cons: SEQUENCE          
 2:d=1  hl=2 l= 32 prim: INTEGER :316EB3CAD8B66FCF1494A6E6F9542C3555ADDBF337F04B62BF4758483FDC881D
36:d=1  hl=2 l= 33 prim: INTEGER :BF46D26CEF45D998A2CB5D2D0B8342D70973FA7C3C37AE72234696524B2BC812

Sie können auch einen Blick auf den OpenSSL-Quellcode werfen, file ecdsa/ecs_asn1.c:

ASN1_SEQUENCE(ECDSA_SIG) = {
        ASN1_SIMPLE(ECDSA_SIG, r, CBIGNUM),
        ASN1_SIMPLE(ECDSA_SIG, s, CBIGNUM)
} ASN1_SEQUENCE_END(ECDSA_SIG)
Hmm, ich habe es geschafft, die beiden Ganzzahlen zu codieren und zu decodieren, aber meiner Codierung scheint das 01-Byte am Ende zu fehlen. Irgendwelche Ideen, warum das so sein könnte? Ich habe das Codeformular hier verwendet - stackoverflow.com/questions/8693513/…
Ich habe eigentlich keine Ahnung, was dieser 01 da macht. Ich werde versuchen, meine Antwort herauszufinden und zu aktualisieren.
01 ist SIGHASH_ALL, das von OP_CHECKSIG verwendet wird, um zu entscheiden, wie die zu signierende Transaktion gehasht werden soll.

R und S sind in jedem der TX-Eingänge sichtbar. Sie können sie bereits extrahiert auf dieser Seite sehen. Ich gebe auch den Z-Wert an.

https://2xoin.com/tx/711b6457b4b2b51e56b94ab541a75d02908648a9de26a3c0ce5b2c3b10573d4e

Weitere Informationen zur Byte-Reihenfolge finden Sie in der Bitcoin-Protokollspezifikation. https://en.bitcoin.it/wiki/Protocol_specification#tx

Unten ist ein Beispiel für ein TX-Eingangshex,

4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

Jetzt getrennt, um es besser lesbar zu machen,

48

3045

0220 (Die Hex 20 sagt, dass die nächsten 32 Bytes der R-Wert sind)

657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c

0221 (Die Hexadezimalzahl 21 besagt, dass die nächsten 33 Bytes der S-Wert sind)

00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e

0141 (Die Hexadezimalzahl 41 besagt, dass die nächsten 65 Bytes der öffentliche Schlüssel sind)

049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

ECDSA r, s-Kodierung als Signatur
AntwortenHierDatenschutz-Bestimmungen1y, 0v