Cryptography: EllipticCurvePublicKey can't be serialized to raw format

[DurandA]

Is there a particular reason not to support raw format (serialization.PublicFormat.Raw and serialization.Encoding.Raw) (x || y in big endian) to serialize an ec.EllipticCurvePublicKey like so:

assert(isinstance(public_key, ec.EllipticCurvePublicKey))
public_bytes = public_key.public_bytes(
    encoding=serialization.Encoding.Raw,
    format=serialization.PublicFormat.Raw
)

Indeed, that is easily achieved using something like that:

pn = public_key.public_numbers()
public_bytes = pn.x.to_bytes(32, byteorder='big') + pn.y.to_bytes(32, byteorder='big')

I think it is quite common to serialize a public key to the raw format. I am willing to make a PR if you think it makes sense to include raw format.

[reaperhulk]

The primary issue here is that "raw" has a specific meaning for ed25519/ed448 in that before they had OIDs to allow embedding in PKCS8 and subjectPublicKeyInfo structures they had a raw little endian encoding.

The "raw" encoding of a NIST/SECG curve is big endian, but what defines that exact format? Are there examples of APIs that import in this fashion? Do they not define it as a specific encoding (e.g. SECG)?

I'm happy to expose more encodings, but we need to be able to point to a spec for them to explain what exactly they are (including all edge cases) and what they're used for.

[DurandA]

Thanks for your answer.

I'm happy to expose more encodings, but we need to be able to point to a spec for them to explain what exactly they are (including all edge cases) and what they're used for.

I agree with your remark. To my surprise, I was unable to find a spec for that and it seems that uncompressed public keys are typically encoded to X9.62.

[ronf]

I can confirm in AsyncSSH that I only use the "Raw" encoding for ED keys. For EC keys, all I need is the X962 format.

[DurandA]

@reaperhulk Do you think it would make sense to support user-defined _encoding_/_format_? I guess that for most formats, the support directly depends on OpenSSL.

[reaperhulk]

Additional standardized serialization forms can potentially be supported directly, but if a user wants to define their own arbitrary encoding formats they should do that in their own code. We have various serialization mechanisms (including the Numbers classes) that can output data that users can transform as needed.