Re: Inconsistent behavior of ECPublicKey_{set,get}_octet_string()?

[Eric Cronin]

On Wednesday, February 19, 2003, at 02:48  PM, Nils Larsch wrote:

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 ?).

I'm working on an implementation of forward-secure signature algorithms, whose keys can sometimes contain multiple RSA/DSA/ECDSA/etc keys. I haven't tackled the best way to PKCS encode these forward-secure keys yet, so in the meantime I have just been using a simple obj1_size||obj1_blob||obj2_size||obj2_blob||... encoding, using i2d_DSAPublicKey and the like when I needed to dump out an OpenSSL key. I will probably switch to putting the raw keys into an EVP_PKEY for the encoding as Steve suggested, but my original goal was just to use the simplest encoding possible since the code will all be removed once a real encoding is decided upon.

                                              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).

OK, maybe "encoding" is the wrong term to have used. What I meant is that all the other (OpenSSL internal datastructure) <-> (char * buffer) functions I can think of have the side effect of advancing the output buffer's pointer after copying the data (unless it allocated the buffer, in which case it doesn't)... The ECPublicKey_{set,get} ones, while having that same common function signature, do not. Maybe this is just i2d/d2i functions vs. all other functions of this nature, in which case I've unfairly singled out ECPublicKey_{set,get}/

I'm not saying that advancing the buffer pointer is the best design (personally I think side effects like that just to save the caller from a simple += are bad), but it would at least be nice if all of OpenSSL's foo_convert(object * foo, char **out) had the same behavior regarding if (!out), if (out && !*out) and if (out && *out) and similarly for the conversion back to in internal datastructure.

Thanks,
Eric

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]