Re: Provider: cannot sign with ed25519-like key

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux