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@xxxxxxxxxxx.
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.
