Re: Provider: cannot sign with ed25519-like key

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.

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
> 

-- 
Bernd Ritter
Senior Linux Developer
Tel.: +49 175 534 4534
Mail: ritter-shG/GajIFYqbacvFa/[email protected]

B1 Systems GmbH
Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de
GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt, HRB 3537

-- 
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/8c691087-f0c2-469f-a927-8237c44790a2%40b1-systems.de.