Re: determining of an EVP_PKEY can do a signature.

Michael Richardson <mcr-SWp7JaYWvAQV+D8aMU/[email protected]> Tue, 26 Aug 2025 18:32:28 -0400
Newsgroups	gmane.comp.encryption.openssl.user
Message-ID	<[email protected]>
Tomas Mraz <[email protected]> wrote:
    >> Okay, step back.  What we really want to know is: can this EVP_PKEY
    >> perform a signature operation.  It seems that perhaps I should just
    >> skip the tests that GetPrivPKeyPtr does, and just depend upon
    >> EVP_DigestSignInit() failing if it can't be done?

    > There is a EVP_PKEY_can_sign(const EVP_PKEY *pkey) function which will
    > give you answer, whether the key type can be used for signing. However
    > it won't check whether there actually is a private key held by the pkey
    > object.

I don't care if there is a literal private key.
In fact, it's exactly the opposite, since a tpm, secure-element, HSM,
etc. won't have that, as the key is elsewhere... but it can sign.

    > We do have a provider API call (the has() function) to discover that
    > but that is not directly exposed via EVP API. Furthermore there might
    > be other reasons (in 3rd party providers) why a key cannot be used for
    > signing such as access rights or similar.

Yes.

    > You can use EVP_PKEY_can_sign() as a sort of pre-check but then you
    > still need to check the result of EVP_DigestSignInit() which can only
    > give you the definitive answer.

Thank you, I think that's what I'm looking for, but reading the man page, I'm
still a bit unclear.  It says:
       EVP_PKEY_can_sign() checks if the functionality for the key type of
       pkey supports signing.  No other check is done, such as whether pkey
       contains a private key.

which suggests to me that it would work for any RSA key, but fail for any ECDH
key: just based upon the type of the key.

    >> EVP_DigestSignInit() still has ENGINE* argument.  While
    >> EVP_DigestSignInit_ex() has OSSL_LIB_CTX.  I find this confusing!

    > The EVP_DigestSignInit() function pre-dates the providers and library
    > contexts, but it will still work with provider-based keys (with the
    > default library context).

    > EVP_DigestSignInit_ex() has to be used if you need non-default library
    > context.

I really would prefer that the EVP_PKEY provided the context.
I don't see why my application/library should need to know this.
From what I can tell from reading code, it seems like it's the MD's context
that wins.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr-SWp7JaYWvAQV+D8aMU/[email protected]  http://www.sandelman.ca/        |   ruby on rails    [



-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe-MCmKBN63+Bmbup2nOX2J7Q@public.gmane.org
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/17744.1756247548%40obiwan.sandelman.ca.
signature.asc (application/pgp-signature, 511 B)