[solved] Re: Provider: cannot sign with ed25519-like key

Hey everyone,

thanks for all the answers. I've circumvented the problem with the 
mislead DIGEST_UPDATE by letting it allow to call DIGEST_UPDATE and 
saving the data into memory.

When DIGEST_UPDATE_FINAL is called, I then call EVP_DigestSign.

Thank you to everyone participating in finding a way!

Cheers,
Bernd

PS: IF there is a way to set a Parameter to enforce block operation, 
please let me know.

Am 14.08.24 um 09:16 schrieb Matt Caswell:
> 
> 
> On 13/08/2024 11:41, 'Bernd Ritter' via openssl-users wrote:
>> The EVP_PKEY_CTX is build up like this in my custom providers 
>> OSSL_FUNC_SIGNATURE_DIGEST_SIGN_INIT:
>>
>>    OSSL_LIB_CTX* lctx = OSSL_LIB_CTX_new();
>>    EVP_PKEY_CTX* pkey_ctx = EVP_PKEY_CTX_new_from_pkey(lctx, pkey, 
>> "provider=default");
>>
>>    EVP_MD_CTX* dflt_md_ctx = EVP_MD_CTX_new();
>>    EVP_MD_CTX_set_pkey_ctx(dflt_md_ctx, pkey_ctx);
>>
>>    EVP_DigestVerifyInit_ex(dflt_md_ctx, NULL, NULL, lctx, 
>> "provider=default", pkey, NULL);
>>    EVP_PKEY_CTX_ctrl_str(pkey_ctx, "instance", "ed25519ph")
>>
>> and in the OSSL_FUNC_SIGNATURE_DIGEST_SIGN i call:
>>
>>    const int rc = EVP_DigestSign(sigctx->md_ctx, sigret, siglen, tbs, 
>> tbslen);
>>
>> The use of <ed25519_digest_sign> is - as far as I understand - correct 
>> behavior - but how does it happen, that <ed25519_digest_update> is 
>> supposed to be called?
> 
> 
> 
> This is how EVP_DigestSign() is implemented:
> 
> https://github.com/openssl/openssl/blob/21bcae6561d73e629f11e19975f24283559d36c0/crypto/evp/m_sigver.c#L579-L610
> 
> As you can see from the above, what it does is first check for the 
> availability of a "digest_sign" function in the fetched signature 
> algorithm. If it exists it calls it. However, if it does not exist for 
> some reason then it will fall back to calling EVP_DigestSignUpdate() 
> followed immediately by EVP_DigestSignFinal().
> 
> But - you can also see from the above that part of the check it does for 
> the availability of the "digest_sign" function is that it checks that 
> the current operation that the ctx has been configured for is
> `EVP_PKEY_OP_SIGNCTX` - i.e. the ctx has been configured for signing.
> 
> But in the above code sample you seem to be calling 
> `EVP_DigestVerifyInit_ex`, i.e. the ctx is not configured for signing 
> but for verifying!!! So it looks to me like when `EVP_DigestSign` is 
> called it stops looks for the digest_sign function when it realises that 
> its been configured for verifying, and then (slightly strangely) 
> proceeds onto the fallback implementation of calling 
> `EVP_DigestSignUpdate` which hasn't been implemented, and therefore it 
> fails.
> 
> The solution would obviously be to call EVP_DigestSignInit_ex() instead 
> of EVP_DigestVerifyInit_ex().
> 
> 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/49921203-052e-42c5-aaa0-4bcb0755623f%40b1-systems.de.