Facing error while writing the generated parameters to PEM file

[ranjithravitk]

Hi,
I generated the parameters for the elgamal encryption scheme as a keydata object and it was passed back to OpenSSL. While generating the PEM file it throws "Error writing error". Through debugging I found that

PEM_write_fnsig(Parameters, EVP_PKEY, BIO, write_bio)
{
    char pem_str[80];
    IMPLEMENT_PEM_provided_write_body_vars(pkey, Parameters, NULL);

    IMPLEMENT_PEM_provided_write_body_main(pkey, bio);

 legacy:
    if (!x->ameth || !x->ameth->param_encode)
        return 0;

    BIO_snprintf(pem_str, 80, "%s PARAMETERS", x->ameth->pem_str);
    return PEM_ASN1_write_bio((i2d_of_void *)x->ameth->param_encode,
                              pem_str, out, x, NULL, NULL, 0, 0, NULL);
}

In the above code, "IMPLEMENT_PEM_provided_write_body_main(pkey, bio);" not getting executed resulting in error. I would like know what can be the root cause for this? Does Keymgmt needs to be in certain structure or is there any particular function that needs to be implemented? My keydata is properly getting assigned in EVP_PKEY structure as well. Any hint will be really helpful. I have been going through the code for a long time and couldn't figure out. Thank you!!

[levitte]

The PEM routines aren't at fault here, neither is keymgmt. However, there is a disconnect, since the PEM routines (or the DER routines that they build upon) cannot know how to deal with your keydata with keymgmt alone.

To enable PEM data to be written, the PEM routines (or well, the DER routines, really, they need the help of an encoder, that belongs in the same provider as the keymgmt, and therefore should know the contents of the keydata, and thereby be able to encode the keydata into a suitable DER or PEM stream.

This is probably among the more complex parts of writing a provider. I suggest starting with provider-encoder(7), and see what you can figure out from there.

[levitte]

Actually, if you successfully wrote encoders, then you should be able to write corresponding decoders, and that should be enough for the default storemgmt. See provider-decoder(7)

You only have to write a new storemgmt if you plan on providing an alternative, not already existing STORE, i.e. a new URI schema. OpenSSL already has full support for file: (which is the default choice of no URI schema is given, which is the case for file paths).

[ranjithravitk]

Thank you so much for the information!!!

[ranjithravitk]

Hi @levitte , I successfully wrote the decoder functions and was able to retrieve the private key as well and I am calling the callback function like this,

        object_type=OSSL_OBJECT_PKEY;
        params[0] = OSSL_PARAM_construct_int(OSSL_OBJECT_PARAM_TYPE, &object_type);
        params[1] = OSSL_PARAM_construct_utf8_string(OSSL_OBJECT_PARAM_DATA_TYPE,
                                                     "ELGAMAL", 0);
        params[2] = OSSL_PARAM_construct_octet_string(OSSL_OBJECT_PARAM_REFERENCE,
                                                      &kdata, sizeof(kdata));
        params[3] = OSSL_PARAM_construct_end();
        if(!data_cb(params,data_cbarg))
          goto err;

I passed back the keydata as a reference and i checked if it is available back in the openssl and it is present. Now openssl tries to construct the key data and in the following code

            struct evp_keymgmt_util_try_import_data_st import_data;
            OSSL_FUNC_store_export_object_fn *export_object =
                ctx->fetched_loader->p_export_object;

            import_data.keymgmt = keymgmt;
            import_data.keydata = NULL;
            import_data.selection = OSSL_KEYMGMT_SELECT_ALL;

            if (export_object != NULL) {
                /*
                 * No need to check for errors here, the value of
                 * |import_data.keydata| is as much an indicator.
                 */
                (void)export_object(ctx->loader_ctx,
                                    data->ref, data->ref_size,
                                    &evp_keymgmt_util_try_import,
                                    &import_data);
            }

            keydata = import_data.keydata;
        }

keydata and p_export_object("file" STORE) both are null. I believe this code executes because the loader is from default "file" STORE and keymgmt is from my provider. import_data.keymgmt = keymgmt; this line has my keymgmt functions as well. I couldn't figure out the root cause for the issue. Am I missing any function that needs to be implemented mandatory? Thanks!!

[levitte]

This... actually looks like a bug in the libcrypto STORE code. Although, this comment a little higher up does say that this is going to happen (and confirms your conclusion):

        /*
         * There are two possible cases
         *
         * 1.  The keymgmt is from the same provider as the loader,
         *     so we can use evp_keymgmt_load()
         * 2.  The keymgmt is from another provider, then we must
         *     do the export/import dance.
         */

But, there is this obvious third situation, that the keydata material comes from the same provider as the keymgmt, i.e. your situation. That's a pretty big omission!

(from over at OpenSSL, I do recall some commentary from the OQS people about the surprise of having to do an export/import dance for STORE purposes... I was much too busy with, er, something else, to pay enough attention on the issue at the time, though)

Looking at how the OQS people solved this, it does seem like you will have to add the export and import functions to your keymgmt implementation, and add the export function to your decoder. I suggest having a look at the OQS provider for inspiration, especially these two files:

• https://github.com/open-quantum-safe/oqs-provider/blob/main/oqsprov/oqs_kmgmt.c
• https://github.com/open-quantum-safe/oqs-provider/blob/main/oqsprov/oqs_decode_der2key.c

In the latter, you'll see how they defined the decoder export function, as essentially a wrapper around their keymgmt export function. That's a pretty sane way of doing things:

https://github.com/open-quantum-safe/oqs-provider/blob/8f37521d5e27ab4d1e0d69a4b4a5bd17927b24b9/oqsprov/oqs_decode_der2key.c#L406-L424

[levitte]

Regarding the omission I mentioned, I took a look around... and it's not exactly easy to resolve that issue, at least at first sight 😖

[ranjithravitk]

Hi @levitte thanks for the information. I was able to resolve the error and it is working now. I am trying to understand how the "pkey" command works. when I run the openssl pkey -provider /usr/lib/x86_64-linux-gnu/ossl-modules/elgamal.so -in /home/kali/openssl/testingprivateky.pem -pubout -out public.pem is decoding my PEM and getting the private key info. But it is not calling my keygen() function of my keymgmt in my provider to generate the public key. Then I checked that only genpkey generates new key and pkey is just working with the provided key file. How can I generate the public key in this command if it will not call the keygen() function?

[levitte]

To generate a key, use openssl genpkey. Something like this should do it:

$ openssl genpkey -provider /usr/lib/x86_64-linux-gnu/ossl-modules/elgamal.so -algorithm elgamal -out testprivkey.pem

If your keymgmt takes OSSL_PARAM parameters of interest, pass them using -pkeyopt {key}:value, where {key} is the OSSL_PARAM name of interest.

[ranjithravitk]

Thank you for the information!! I have one last doubt and I apologise for the constant badgering 🙏. Can I store the public key as well in my private key PEM file. When I executed the genpkey command, the selection bit that I got was "3" which pointed towards keypair generation. Following that I can extract the public key using "pkey" command. Thank you!!