Eric Cronin wrote:
> I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
> functions for ECDSA EC_KEY's.
May I ask why ? For X9.62 you don't need them (, or do
you mean a X509 SubjectPublicKeyInfo object ?).
> As best I can tell,
> i2dECPKParameters+ECPublicKey_get_octet_string and
> d2iECPKParameters+ECPublicKey_set_octet_string are the way to do the
> encoding/decoding of just the public portions of an EC_KEY. However,
> unlike all the other encoding routines in OpenSSL,
> ECPublicKey_{set,get}_octet_string() does not advance the supplied
> buffer after copying the key to it.
The ECPublicKey_{set|get}_octet_string() functions should simply return
(or set) the public key as an octet string (as the name suggest). They have
nothing to do with ASN1 DER encoding => no i2d or d2i prefix.
Note: the ec public key in the X509 SubjectPublicKeyInfo object is not
DER encoded (the most significant bit of the public key (encoded
as an octet string) becomes the most significant bit of the bit string).
> Instead, if *in is non-NULL, it remains pointing to the start of the
> copied key after the function returns (In every other encoding routine
> I've used *in is advanced to point to the byte after the just encoded
> data).
ECPublicKey_{set|get}_octet_string() are *not* DER de/encoding routines.
> Is there a reason these functions deviates from the normal OpenSSL
> behavior? It was hard enough to figure out the unwritten rules of when
> the input buffer does and does not get advanced to begin with, and now
> if some functions adhere to it and some don't...
Sorry, perhaps I should add some comments in the corresponding
code section ...
Regards,
Nils
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
