Re: Provider: cannot sign with ed25519-like key

On 12/08/2024 14:17, 'Bernd Ritter' via openssl-users wrote:
> Hey there,
> 
> debugging actually solved it, there was a silent other error that caused 
> problems, but not visual problem I saw. Got that fixed, many thanks for 
> that!
> 
> Following through with debugging I got to the next road block. My 
> provider is now trying to sign some payload. It calls 
> OSSL_FUNC_SIGNATURE_DIGEST_SIGN_UPDATE for the first time. I guess this 
> should be OSSL_FUNC_SIGNATURE_DIGEST_SIGN, but I have no idea to enforce 
> this.
> 
> It's the same context, same data, same data size.

You say its the same context, and yet the ctx pointer seems to be 
different in the debugging output you showed, i.e. ctx=0x5555556a2e40 
compared to ctx=0x5555556bac40.

So are you sure it is the same ctx?

Matt

> 
> Breakpoint 1, EVP_DigestSignUpdate (ctx=0x5555556a2e40, 
> data=0x7fffffffc3b0, dsize=29) at crypto/evp/m_sigver.c:419
> 423         if (pctx->op.sig.signature->digest_sign_update == NULL) {
> 428         return pctx->op.sig.signature->digest_sign_update(pctx- 
>  >op.sig.algctx,
> (gdb) n
> ed25519ph-provider/src/ed25519ph_sign_x509.c - digest sign update. 
> datalen=29
> 
> Now when the provider wants to close the deal, the digest_sign_update 
> from the context is now NULL suddenly.
> 
> Breakpoint 1, EVP_DigestSignUpdate (ctx=0x5555556bac40, 
> data=0x7fffffffc3b0, dsize=29) at crypto/evp/m_sigver.c:419
> 423         if (pctx->op.sig.signature->digest_sign_update == NULL) {
> 424             ERR_raise(ERR_LIB_EVP, ERR_R_SHOULD_NOT_HAVE_BEEN_CALLED);
> 
> ed25519ph-provider/src/ed25519ph_sign_x509.c - digest sign update failed 
> rc=0. error:030C0101:digital envelope routines::called a function you 
> should not call
> Error signing raw input data
> Public Key operation error
> 
> I've also tried the "trick" from Steffen who mentioned earlier a hacky 
> way to enforce block operation.
> 
> All the best,
> Bernd
> 
> Am 12.08.24 um 12:33 schrieb Matt Caswell:
>>
>>
>> On 12/08/2024 11:08, 'Bernd Ritter' via openssl-users wrote:
>>> I do not understand how the parameter list can change? As my 
>>> debugging logs are called, it seems that my get_params is called 
>>> accordingly.
>>>
>>
>> I don't really understand what you mean by this. Each invocation of 
>> your get_params function may request different parameters depending on 
>> which parameters the caller is interested in for any given context.
>>
>> As I previously mentioned the "unknown max size" error comes from the 
>> EVP_PKEY_get_size() function, and this ultimately gets the size by 
>> querying the OSSL_PKEY_PARAM_MAX_SIZE parameter.
>>
>> The value of this parameter is cached in the pkey. This happens here 
>> in OpenSSL:
>>
>> https://github.com/openssl/openssl/ 
>> blob/2f33265039cdbd0e4589c80970e02e208f3f94d2/crypto/evp/ 
>> keymgmt_lib.c#L289-L313
>>
>> This is the point in libcrypto where your provider is called and the 
>> OSSL_PKEY_PARAM_MAX_SIZE parameter is queried - the result of which is 
>> cached in the cache.size field of the pkey. All subsequent calls to 
>> `EVP_PEKY_get_size()` will refer to this cache and give the "unknown 
>> max_size" error if this cached size is <= 0.
>>
>> If you are struggling to see how this fits together with what your 
>> code is doing then I suggest you build OpenSSL with debug symbols on 
>> and set a breakpoint in the `evp_keymgmt_util_cache_keyinfo` function 
>> I linked to above and step through what is happening in the 
>> interaction with your provider.
>>
>> Matt
>>
> 

-- 
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 on the web visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/ad77afee-7149-4ffe-8ab0-b3d914bd2dff%40openssl.org.