Re: Provider: cannot sign with ed25519-like key

On 12/08/2024 14:27, 'Bernd Ritter' via openssl-users wrote:
> Hey Matt,
> 
> yeah point on. Its too hot I guess, was just checking the last memory 
> address numbers.
> 
> So you mean that somewhere the context contains a "wrong" key?

Potentially. It's unclear. My point was simply that the ctx pointers 
were different. If you are expecting them to be the same then you need 
to figure out why they're not.

Matt

> 
> Bernd
> 
> Am 12.08.24 um 15:22 schrieb Matt Caswell:
>>
>>
>> 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/19d27fc6-00cd-4b2e-9631-738275dfa3fb%40openssl.org.