Hey again,
the two contexts are fine and intended, one context is the ED25519 key
with the custom OID within the custom provider's context.
The other context is the default (OpenSSL) ED25519 context. And here's
where the error unfolds.
As I know (and was state here before) ED25519 currently only supports
block operations. Thus it should use <ed25519_digest_sign>.
When I load the EVP_PKEY from the keymanagement with the raw key and
build up a new EVP_PKEY from it, the DigestSign wants somehow to call
<ed25519_digest_update> which is not linked as a function pointer in the
EVP_PKEY struct.
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?
The private key is loaded in keymangement load:
static void *keymgmt_load(const void *reference, size_t reference_sz)
EVP_PKEY* pkey = EVP_PKEY_new_raw_private_key_ex(NULL, "ED25519",
"provider=default", (const unsigned char*) reference, reference_sz);
return pkey;
}
Now the debugger shows, that sign_update_fn is NULL (which is supposed
to be)
(gdb) p pctx->op.sig.signature.digest_sign_update
$4 = (OSSL_FUNC_signature_digest_sign_update_fn *) 0x0
(gdb) p pctx->op.sig.signature.digest_sign
$5 = (OSSL_FUNC_signature_digest_sign_fn *) 0x7ffff7ca87d4
<ed25519_digest_sign>
How can this happen? Is loading the ED25519 evp_key from the raw data
somehow wrong or incomplete?
All the best,
Bernd
Am 12.08.24 um 16:17 schrieb Matt Caswell:
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
--
Bernd Ritter
Senior Linux Developer
Tel.: +49 175 534 4534
Mail: ritter@xxxxxxxxxxxxx
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@xxxxxxxxxxx.
To view this discussion on the web visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/38223771-9104-44a4-8c3f-5c4dc8ca4ddd%40b1-systems.de.
