OpenSSL libcrypto: как EC_POINT_point2oct() кодирует свой результат? Это портативный?

EC_POINT_point2oct(ecGroup,EC_KEY_get0_public_key(ключ),POINT_CONVERSION_COMPRESSED,_pub._key, SizeOf(_pub._key),0)

Это не будет что-то высокого уровня, как DER, PKCS* или что-то вроде ASN.1. (Не так ли?) Я угадываю сырой BN, содержащий сжатую точку EC.

Мне любопытно, может ли этот результат быть перенесен на другие языки, например, Java с использованием классов EC BouncyCastle.

2 ответа

Решение

Если вы просмотрите источник достаточно глубоко, вы увидите такие заявления:

ret = (form == POINT_CONVERSION_COMPRESSED) ? 1 + field_len : 1 + 2*field_len;

поэтому не следует применять какую-либо дополнительную кодировку, как вы ожидали. Конечно, это тоже достаточно просто.

Возврат сжатой точки не должен быть слишком сложным. Получение значения обратно сложнее и может привести к проблемам с патентами на программное обеспечение.

Скорее всего, он будет в формате ANSI X9.62, который является очень стандартным, да, он используется, например, для кодирования точек EC в рукопожатиях TLS.

В частности, классы EC BouncyCastle могут читать их, поддерживая несжатые, сжатые и гибридные кодировки (в основном все). В облегченном API, если у вас есть экземпляр org.bouncycastle.math.ec.ECCurve, вы можете вызвать ECCurve.decodePoint для кодировки, чтобы вернуть ECPoint на кривой. Затем экземпляры ECPoint можно использовать для создания открытых / закрытых ключей.

Если вы используете BC (или, как я полагаю, большинство других провайдеров) через JCE, я был бы уверен, что их декодировать через этот API также просто.

Другие вопросы по тегам