Кодировка ECDSA r, s в качестве подписи

Алгоритм ECDSA при подписании данных сообщений создает пару выходных данных, r и s . Как, имея sigStr из Tx, можно извлечь r и s? Являются ли они просто конкатенированными массивами байтов определенной длины или что-то еще?

Ответы (2)

Если вы хотите, вы можете заплатить 100 долларов за стандарт ANSI X9.62 . Или вы можете схитрить и посмотреть RFC3278, раздел 8.2 . Это в формате DER, состоящем из ПОСЛЕДОВАТЕЛЬНОСТИ двух ЦЕЛЫХ ЦЕЛЫХ. Первое INTEGER равно r, второе s.

Если вы посмотрите на эту транзакцию , то увидите, что одна из подписей:

3045 0220
316eb3cad8b66fcf1494a6e6f9542c3555addbf337f04b62bf4758483fdc881d
022100
bf46d26cef45d998a2cb5d2d0b8342d70973fa7c3c37b96524b962234

Если мы разберем это как DER, мы получим:

 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

Вы также можете просмотреть исходный код OpenSSL, файл 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)
Хм, мне удалось закодировать и декодировать два целых числа, но в моей кодировке, похоже, отсутствует 01 байт в конце. Любые идеи, почему это может быть так? Я использовал форму кода здесь - stackoverflow.com/questions/8693513/…
На самом деле я понятия не имею, что этот 01 там делает. Я постараюсь узнать и обновить свой ответ.
01 — это SIGHASH_ALL, используемый OP_CHECKSIG, чтобы решить, как хэшировать подписываемую транзакцию.

R и S видны на каждом из входов tx. Вы можете увидеть их уже извлеченными на этом сайте. Я также предоставляю значение Z.

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

См. спецификацию протокола биткойн для получения дополнительной информации о порядке байтов. https://en.bitcoin.it/wiki/Спецификация_протокола#tx

Ниже приведен пример шестнадцатеричного ввода TX,

4830450220657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c022100ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e0141049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

Теперь разделены, чтобы облегчить чтение,

48

3045

0220 (Hex 20 говорит, что следующие 32 байта являются значением R)

657912a72d3ac8169fe8eaecd5ab401c94fc9981717e3e6dd4971889f785790c

0221 (Шестнадцатеричный 21 говорит, что следующие 33 байта являются значением S)

00ed3bf3456eb76677fd899c8ccd1cc6d1ebc631b94c42f7c4578f28590d651c6e

0141 (Шестнадцатеричный код 41 говорит, что следующие 65 байт являются открытым ключом)

049b5506df53ff5eff7dc553131043bb993f55d2b0fddd866984f593777023c8226920ff05747ccb963f0fe459cb217d502e57dcf8afec786c3dcee4d1558f85fa

Кодировка ECDSA r, s в качестве подписи
СпросиСетьПолитика конфиденциальности1y, 2v