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

Question

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 с использованием классов BouncyCastle EC.

Answer 1

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

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

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

Возврат сжатой точки не должен быть слишком сложным. Возврат значения обратно сложнее и может получить вас into trouble regarding software patents.

Answer 2

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

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

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