On Tue, Nov 22, 2022 at 11:09:07AM -0600, Nico Williams wrote:
> > 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.
Actually, it supports *both* the PKCS#8 and the legacy type-specific formats.
The algorithm-specific PEM key formats may not be defined for some newer
key types and are deprecated, so sure, you're supposed to use PKCS#8
whenever possible.
For EC private keys, the underlying legacy DER codecs are:
d2i_ECPrivateKey()
i2d_ECPrivateKey()
with signatures:
EC_KEY *d2i_ECPrivateKey(EC_KEY **a, const unsigned char **in, long len);
int i2d_ECPrivateKey(const EC_KEY *a, unsigned char **out);
for d2i_ECPrivateKey(), you get back an EC_KEY() which you can convert
to an EVP_PKEY via the deprecated (copy vs. take ownership):
EVP_PKEY_set1_EC_KEY(3), or EVP_PKEY_assign_EC_KEY(3)
which direct you to EVP_PKEY_fromdata(3) (much scaffolding...).
However, d2i_PrivateKey(EVP_PKEY_EC, ...) given non-PKCS#8 input
internally tries:
static int old_ec_priv_decode(EVP_PKEY *pkey,
const unsigned char **pder, int derlen)
{
EC_KEY *ec;
if ((ec = d2i_ECPrivateKey(NULL, pder, derlen)) == NULL)
return 0;
EVP_PKEY_assign_EC_KEY(pkey, ec);
return 1;
}
which does the expected thing without much fuss. That said, you
mentioned ECDH in passing, so I'm not sure we're taking about the same
things...
--
Viktor.
