1

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.

AdamIerymenko
  • 1,299
  • 2
  • 10
  • 19

2 Answers2

2

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.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • 1
    The method described in the linked patent is not the same as the ANSI X9.62 compression that is presumably being used here. Given the X9.62 format is used by TLS, it seems unlikely that it's patent-encumbered. – Peter Dettman Aug 02 '13 at 12:52
2

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.

Peter Dettman
  • 3,867
  • 20
  • 34