On Wed, Feb 19, 2003, Eric Cronin wrote:
> I am trying to find the analogue of the {i2d,d2i}_{DSA,RSA}PublicKey
> functions for ECDSA EC_KEY's. 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.
> 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).
>
Although the key specific RSAPublicKey and RSAPrivateKey functions follow a
written standard (PKCS#1) the DSAPublicKey and DSAPrivateKey ones AFAIK do
not: they were made up for SSLeay and we're now stuck with them.
Rather than make up a new format that would be incompatible with everything
else I'd prefer it that we didn't have any equivalents at all for newer
algorithms.
The preferred technique for handling all types of public keys is the
{i2d,d2i}_PUBKEY functions and EVP_PKEY. These use the standard certificate
format for public keys. This isn't algorithm specific and there are various
standards that define the formats used.
There are key specific key types such as {i2d,d2i}_RSA_PUBKEY. These just call
the PUBKEY type and insert or extract the algorithm specific key, throwing an
error if the key isn't of the expected type.
The EC equivalents are d2i_EC_PUBKEY and i2d_EC_PUBKEY.
Similarly PKCS#8 is the preferred private key format.
> 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...
>
A lot more of that stuff is documented since 0.9.7 but not all the EC stuff:
its very new.
Steve.
--
Dr Stephen N. Henson.
Core developer of the OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.demon.co.uk/
Email: [EMAIL PROTECTED], PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
