HSM возвращает 67-байтовый открытый ключ ECDSA-secp256k1, что это значит?

Question

Я генерирую ключ на HSM через библиотеку Graphene, за исключением случаев, когда я пытаюсь получить необработанное значение открытого ключа, получая его атрибут 'pointEC' (эквивалентный CKA_EC_POINT), я получаю строку из 134 символов:

044104c9d5b656518b5b7e0d747b86328c37a0d507de9b3863a43e77b559ab60c0f9b15985f83a8c20588164c0634f98eb4a4cf8ce70020e94ae21a247904fac8b1010

Теперь я понимаю, что для этого стандарта есть целые числа X и Y, но я прочитал, что требуется некоторая математика, чтобы сделать их действительными для генерации адреса Эфириума.Я также понимаю, что «04» означает, что это несжатый открытый ключ, но я не знаю, почему «4104» продолжает появляться или что это значит.Это просто разные способы представления одних и тех же данных?Могу ли я просто взять последние 128 символов и хешировать его для действительного адреса Эфириума?

Answer 1

То, что вы видите, - это несжатая точка, кодированная BER / DER . Первый байт со значением 04 является , а не индикатором несжатой точки. Это третий байт. Первый байт со значением 04 кодирует байт тега для строки октетов ASN.1 (большинству разработчиков также известен как массив байтов). Вы можете просмотреть структуру здесь .

Байт с шестнадцатеричным значением 41 - это размер байтов, который идет после: 1 байт для индикатора несжатой точки 04, 32 байта для статической величины X-координата и 32 байта для координаты Y.

Так что да, вы можете взять последние 64 байта и разделить их на два, если вам нужны координаты X и Y. 128 символов - это шестнадцатеричное представление этих байтов, но вам следует просто побеспокоиться о байтах.

Конечно, должен сделать, чтобы проанализировать ASN.1, определить и проверить длину, взять несжатую точку, декодировать ее и проверить, что она находится на кривой чтобы подтвердить ваш вклад. Ключ EC действителен, если он содержит правильные параметры. Однако для Ethereum / BitCoin кривая неявно известна (secp256k1).