Question about migrating from d2i_ECPrivateKey() to d2i_PrivateKey(EVP_PKEY_EC, ...)

Nico Williams nico at cryptonector.com
Tue Nov 22 17:09:07 UTC 2022


On Sun, 20 Nov 2022 17:15:06 -0500, Viktor Dukhovni wrote:
> On Sun, Nov 20, 2022 at 02:12:34PM -0600, Nico Williams wrote:
> > > Generally, I would expect d2i_... to automatically detect the algorithm
> > > when tagged with a suitable OIDs, and so d2i_AutoPrivateKey() could
> > > often work, but if you know the expected key type, you can ask for
> > > that explicitly with d2i_PrivateKey().
> >
> > So, d2i_PrivateKey() wants a PKCS#8 wrapper so it can figure out what
> > the type of the private key blob is.
> 
> Not exactly, PKCS#8-based typing is used in d2i_PKCS8_PRIV_KEY_INFO()
> (for unencrypted PKCS#8 blobs, so no password callback).  The
> d2i_PrivateKey() function takes an explicit pkey_type instead.

Hmmm, well, d2i_PrivateKey() takes an explicit pkey_type, yes, but it's
not sufficiently informative for ECDH, being just EVP_PKEY_EC.  Or are
there more informative type values I've not discovered yet?  When I call
d2i_PrivateKey(EVP_PKEY_EC, ...) it wants a PKCS#8 encoded private key.

If there's a more specific type than EVP_PKEY_EC that I could use so
that d2i_PrivateKey() can decode just the raw private key, that'd be
great.  I couldn't find such a type.

> > On the other hand, d2i_PublicKey() wants the input key to indicate the
> > type of public key to import.  A strange asymmetry, but it works.
> > Staring at Postfix and OpenSSL code helped.
> 
> For X.509 SPKI public keys (the ones you generally want to use) the right
> interface is d2i_PUBKEY, not d2i_PublicKey().

Thanks, good to know.  d2i/i2d_PUBKEY() uses the OSSL_ENCODER API
internally.  Where do I find out what all the supported output_type /
output_struct values are.

Also, the prototype for i2d_PUBKEY() does not appear in any header,
public or private, but i2d_PUBKEY() _is_ documented -- is this a bug?

Thanks,

Nico
-- 


More information about the openssl-users mailing list