CODEWITHSUNDEEP
cryptographybouncycastleelliptic-curvelibcrypto
AdamIerymenko
AdamIerymenko

Reputation: 1329

OpenSSL libcrypto: how does EC_POINT_point2oct() encode its result? Is it portable?

EC_POINT_point2oct(ecGroup,EC_KEY_get0_public_key(key),POINT_CONVERSION_COMPRESSED,_pub._key,sizeof(_pub._key),0)

It wouldn't be anything high level like DER, PKCS*, or anything ASN.1. (Would it?) I'm guessing a raw BN containing an EC compressed point.

I'm curious as to whether this result is something that could be ported to other languages, e.g. Java using BouncyCastle's EC classes.

Upvotes: 1

Views: 1857

Answers (2)

Peter Dettman
Peter Dettman

Reputation: 4062

It seems likely to just be in the ANSI X9.62 format, which is very standard, yes, being used e.g. to encode EC points in TLS handshakes.

In particular, BouncyCastle's EC classes can read them, supporting uncompressed, compressed, and hybrid encodings (basically everything). In lightweight API, if you have an instance of org.bouncycastle.math.ec.ECCurve, you can call ECCurve.decodePoint on the encoding to get back an ECPoint on the curve. ECPoint instances can then be used to create public/private keys.

If you are using BC (or most other providers, I expect) via JCE, I'd be confident it's straight-forward to decode them via that API too.

Upvotes: 2

Maarten Bodewes
Maarten Bodewes

Reputation: 94078

If you browse the source deep enough you will see statements such as these:

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

so it should not apply any additional encoding, as you expected. It is easy enough try too, of course.

Returning a compressed point should not be too hard. Retrieving the value back is trickier and may get you into trouble regarding software patents.

Upvotes: 2

Related Questions