Re: Store Mgmt and keys loading ( keyform ENG )
Piotr, I can see what you mean now during debugging. I have now managed to set the flags in the RSA structure, not only in the RSA_METHOD. One point I noticed is that you need to explicitly fill in all of the methods in RSA_METHOD now , so those that you don't want to override must be got from the default and set them accordingly in RSA_METHOD structure. I still have to pass back a valid key to dgst's callback from the store mgmt's load() otherwise the call chain complains for missing key. This shouldn't be needed in my opinion if RSA_FLAG_EXT_PKEY is set . On Tue, Oct 12, 2021 at 1:35 PM Piotr Lobacz wrote: > I'm sorry i cannot help you with providers. All i can tell you, is that in > my case libpkcs11 was not setting using RSA_meth_set_flags but > RSA_set_flags and in dotnet openssl implementation, the check was being > made on the method. I was thinking that our issues may be related. > > BR > Piotr > ---------- > *Od:* Antonio Santagiuliana > *Wysłane:* wtorek, 12 października 2021 10:50 > *Do:* Piotr Lobacz ; openssl-users@openssl.org > > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > in general, I think that despite what I read in previous replies, > with the operation: > dgst --provider=myprovider -sign handle:1 > is not possible to fully reproduce what was possible with engines : > dgst -keyform ENG sign -in 1 -engine=myengine. > In the case of provider the store manager's caller sets > ossl_store_handle_load_result as fixed callback method when calling the > load of store mgmt. If that callback is not called , it will complain as no > private key is possible to read. > > > On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana < > santantonios...@gmail.com> wrote: > > Thank you for the suggestion. > I am using providers though, not engine, and I can't see the higher level > checking this RSA flags before it has detected a valid key is passed back > from the store manager to ossl_store_handle_load_result() ( the callback > passed to the store mgmt load() method). > If I don't call the callback ossl_store_handle_load_result the higher > level after the store mgmt load() complains no private key can be read. > If I pass back an RSA key generated on the fly in the store mgmt load() > then the ossl_store_handle_load_result() is fine using the RSA key mgmt > load finds error in checking RSA flags , I think these flags are not set > but I don't know how to set them in the fictitious private key I generated > on the fly in the store mgmt load() with > EVP_PKEY *pkey = NULL; > pkey = EVP_RSA_gen(2048); > This produces a valid pkey without errors but I think the rsa fields are > not filled in.How can I add them to pkey ? > I think I should register a different keymgmt on my provider but I am not > sure what it should do in my case. > So , for now, the RSA keymgmt is called and in its load() function > ( rsa_load() ) at some point it wants to check RSA_check_flags() and there > it stops as the rsa struct fileds referenced are not filled in. > > > > On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote: > > Hi Antonio, > I was discussing about this problem about half a year ago in here. The > problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in > RSA_METHOD which is wrong. Yo can read it in here > https://github.com/dotnet/runtime/issues/53345. The clue of my problem > was that this flag was being set by the dotnet and engine was setting it in > RSA_set_flags - which is the proper way. You need to verify how the engine > sets this flag and read my issue maybe it will help you in solving yours. > > BR > Piotr > -- > *Od:* openssl-users w imieniu > użytkownika Antonio Santagiuliana > *Wysłane:* piątek, 8 października 2021 10:34 > *Do:* Tomas Mraz > *DW:* openssl-users@openssl.org > *Temat:* Re: Store Mgmt and keys loading ( keyform ENG ) > > Could I ask you what is the best way to let the Openssl carry on in the > case I can't pass the private key from my store manager load() function as > key is offloaded in secure hw? > I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the > callback function from my Store Mgmt's load() where I get the uri ( the > callback func is ossl_store_handle_load_result() ) I get error "could not > read the private key". > If instead I call the callback func , I don't know how to fill in its > params , as I don't have the private key. What should I put in the params > to let the rest of call chain ( I am on the dgst command ) not caring about > private key but carry on with operation?or can I avoid calling the callback? > Thank you > > On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, < > santantonios...
Re: Store Mgmt and keys loading ( keyform ENG )
in general, I think that despite what I read in previous replies,
with the operation:
dgst --provider=myprovider -sign handle:1
is not possible to fully reproduce what was possible with engines :
dgst -keyform ENG sign -in 1 -engine=myengine.
In the case of provider the store manager's caller sets
ossl_store_handle_load_result as fixed callback method when calling the
load of store mgmt. If that callback is not called , it will complain as no
private key is possible to read.
On Tue, Oct 12, 2021 at 9:22 AM Antonio Santagiuliana <
santantonios...@gmail.com> wrote:
> Thank you for the suggestion.
> I am using providers though, not engine, and I can't see the higher level
> checking this RSA flags before it has detected a valid key is passed back
> from the store manager to ossl_store_handle_load_result() ( the callback
> passed to the store mgmt load() method).
> If I don't call the callback ossl_store_handle_load_result the higher
> level after the store mgmt load() complains no private key can be read.
> If I pass back an RSA key generated on the fly in the store mgmt load()
> then the ossl_store_handle_load_result() is fine using the RSA key mgmt
> load finds error in checking RSA flags , I think these flags are not set
> but I don't know how to set them in the fictitious private key I generated
> on the fly in the store mgmt load() with
> EVP_PKEY *pkey = NULL;
> pkey = EVP_RSA_gen(2048);
> This produces a valid pkey without errors but I think the rsa fields are
> not filled in.How can I add them to pkey ?
> I think I should register a different keymgmt on my provider but I am not
> sure what it should do in my case.
> So , for now, the RSA keymgmt is called and in its load() function
> ( rsa_load() ) at some point it wants to check RSA_check_flags() and there
> it stops as the rsa struct fileds referenced are not filled in.
>
>
>
> On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote:
>
>> Hi Antonio,
>> I was discussing about this problem about half a year ago in here. The
>> problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in
>> RSA_METHOD which is wrong. Yo can read it in here
>> https://github.com/dotnet/runtime/issues/53345. The clue of my problem
>> was that this flag was being set by the dotnet and engine was setting it in
>> RSA_set_flags - which is the proper way. You need to verify how the engine
>> sets this flag and read my issue maybe it will help you in solving yours.
>>
>> BR
>> Piotr
>> --
>> *Od:* openssl-users w imieniu
>> użytkownika Antonio Santagiuliana
>> *Wysłane:* piątek, 8 października 2021 10:34
>> *Do:* Tomas Mraz
>> *DW:* openssl-users@openssl.org
>> *Temat:* Re: Store Mgmt and keys loading ( keyform ENG )
>>
>> Could I ask you what is the best way to let the Openssl carry on in the
>> case I can't pass the private key from my store manager load() function as
>> key is offloaded in secure hw?
>> I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the
>> callback function from my Store Mgmt's load() where I get the uri ( the
>> callback func is ossl_store_handle_load_result() ) I get error "could not
>> read the private key".
>> If instead I call the callback func , I don't know how to fill in its
>> params , as I don't have the private key. What should I put in the params
>> to let the rest of call chain ( I am on the dgst command ) not caring about
>> private key but carry on with operation?or can I avoid calling the callback?
>> Thank you
>>
>> On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, <
>> santantonios...@gmail.com> wrote:
>>
>> It is because of prototypes of methods..
>>
>> On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <
>> santantonios...@gmail.com> wrote:
>>
>> Hello,
>> just continuing on this..
>> I defined my store mgmt as :
>> static const OSSL_ALGORITHM test_store[] = {
>> { "handle", "provider=test", mystore_functions},
>> {NULL, NULL, NULL}
>> };
>>
>> echo "test" | LD_LIBRARY_PATH=.apps/openssl dgst
>> --provider-path=./providers --provider=test --sign handle:1 -out
>> messa.encrypted.bin
>>
>> Could not open file or uri for loading private key from handle:1
>>
>> C0628C24787F:error:1669:STORE
>> routines:ossl_store_get0_loader_int:unregistered
>> scheme:crypto/store/store_register.c:237:scheme=file
>>
>> C0628C24787F:error:1608010C:STORE
>> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
>> store loader found. For standard store loaders you
Re: Store Mgmt and keys loading ( keyform ENG )
Thank you for the suggestion.
I am using providers though, not engine, and I can't see the higher level
checking this RSA flags before it has detected a valid key is passed back
from the store manager to ossl_store_handle_load_result() ( the callback
passed to the store mgmt load() method).
If I don't call the callback ossl_store_handle_load_result the higher level
after the store mgmt load() complains no private key can be read.
If I pass back an RSA key generated on the fly in the store mgmt load()
then the ossl_store_handle_load_result() is fine using the RSA key mgmt
load finds error in checking RSA flags , I think these flags are not set
but I don't know how to set them in the fictitious private key I generated
on the fly in the store mgmt load() with
EVP_PKEY *pkey = NULL;
pkey = EVP_RSA_gen(2048);
This produces a valid pkey without errors but I think the rsa fields are
not filled in.How can I add them to pkey ?
I think I should register a different keymgmt on my provider but I am not
sure what it should do in my case.
So , for now, the RSA keymgmt is called and in its load() function
( rsa_load() ) at some point it wants to check RSA_check_flags() and there
it stops as the rsa struct fileds referenced are not filled in.
On Fri, 8 Oct 2021, 22:04 Piotr Lobacz, wrote:
> Hi Antonio,
> I was discussing about this problem about half a year ago in here. The
> problem was itself in .net library but it concerned RSA_FLAG_EXT_PKEY in
> RSA_METHOD which is wrong. Yo can read it in here
> https://github.com/dotnet/runtime/issues/53345. The clue of my problem
> was that this flag was being set by the dotnet and engine was setting it in
> RSA_set_flags - which is the proper way. You need to verify how the engine
> sets this flag and read my issue maybe it will help you in solving yours.
>
> BR
> Piotr
> --
> *Od:* openssl-users w imieniu
> użytkownika Antonio Santagiuliana
> *Wysłane:* piątek, 8 października 2021 10:34
> *Do:* Tomas Mraz
> *DW:* openssl-users@openssl.org
> *Temat:* Re: Store Mgmt and keys loading ( keyform ENG )
>
> Could I ask you what is the best way to let the Openssl carry on in the
> case I can't pass the private key from my store manager load() function as
> key is offloaded in secure hw?
> I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the
> callback function from my Store Mgmt's load() where I get the uri ( the
> callback func is ossl_store_handle_load_result() ) I get error "could not
> read the private key".
> If instead I call the callback func , I don't know how to fill in its
> params , as I don't have the private key. What should I put in the params
> to let the rest of call chain ( I am on the dgst command ) not caring about
> private key but carry on with operation?or can I avoid calling the callback?
> Thank you
>
> On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana, <
> santantonios...@gmail.com> wrote:
>
> It is because of prototypes of methods..
>
> On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <
> santantonios...@gmail.com> wrote:
>
> Hello,
> just continuing on this..
> I defined my store mgmt as :
> static const OSSL_ALGORITHM test_store[] = {
> { "handle", "provider=test", mystore_functions},
> {NULL, NULL, NULL}
> };
>
> echo "test" | LD_LIBRARY_PATH=.apps/openssl dgst
> --provider-path=./providers --provider=test --sign handle:1 -out
> messa.encrypted.bin
>
> Could not open file or uri for loading private key from handle:1
>
> C0628C24787F:error:1669:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=file
>
> C0628C24787F:error:1608010C:STORE
> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
> store loader found. For standard store loaders you need at least one
> of the default or base providers available. Did you forget to load
> them? Info: Global default library context, Scheme (file : 0),
> Properties ()
>
> C0628C24787F:error:1669:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=handle
>
> 1) It firstly looks for a provider for scheme file: and it doesn't
> find as I haven't set up any store mgmt for file: .
>
> 2) It looks like on second attempt it tries to look for handle: but it
> finds it not registered. What does this error mean ? Does it look for
> registered uri schemes online ? if that is the case how can this works
> instead : https://github.com/tpm2-software/tpm2-openssl ? They use
> handle: scheme as well.
>
> Does this mean it's a problem of the methods I registered for the
> store or is something related to the uri scheme I am using ?
> Sor
Re: Store Mgmt and keys loading ( keyform ENG )
Could I ask you what is the best way to let the Openssl carry on in the
case I can't pass the private key from my store manager load() function as
key is offloaded in secure hw?
I have set RSA_FLAG_EXT_PKEY in RSA_METHOD but if I don't call the callback
function from my Store Mgmt's load() where I get the uri ( the callback
func is ossl_store_handle_load_result() ) I get error "could not read the
private key".
If instead I call the callback func , I don't know how to fill in its
params , as I don't have the private key. What should I put in the params
to let the rest of call chain ( I am on the dgst command ) not caring about
private key but carry on with operation?or can I avoid calling the callback?
Thank you
On Thu, 7 Oct 2021, 09:47 Antonio Santagiuliana,
wrote:
> It is because of prototypes of methods..
>
> On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana, <
> santantonios...@gmail.com> wrote:
>
>> Hello,
>> just continuing on this..
>> I defined my store mgmt as :
>> static const OSSL_ALGORITHM test_store[] = {
>> { "handle", "provider=test", mystore_functions},
>> {NULL, NULL, NULL}
>> };
>>
>> echo "test" | LD_LIBRARY_PATH=.apps/openssl dgst
>> --provider-path=./providers --provider=test --sign handle:1 -out
>> messa.encrypted.bin
>>
>> Could not open file or uri for loading private key from handle:1
>>
>> C0628C24787F:error:1669:STORE
>> routines:ossl_store_get0_loader_int:unregistered
>> scheme:crypto/store/store_register.c:237:scheme=file
>>
>> C0628C24787F:error:1608010C:STORE
>> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
>> store loader found. For standard store loaders you need at least one
>> of the default or base providers available. Did you forget to load
>> them? Info: Global default library context, Scheme (file : 0),
>> Properties ()
>>
>> C0628C24787F:error:1669:STORE
>> routines:ossl_store_get0_loader_int:unregistered
>> scheme:crypto/store/store_register.c:237:scheme=handle
>>
>> 1) It firstly looks for a provider for scheme file: and it doesn't
>> find as I haven't set up any store mgmt for file: .
>>
>> 2) It looks like on second attempt it tries to look for handle: but it
>> finds it not registered. What does this error mean ? Does it look for
>> registered uri schemes online ? if that is the case how can this works
>> instead : https://github.com/tpm2-software/tpm2-openssl ? They use
>> handle: scheme as well.
>>
>> Does this mean it's a problem of the methods I registered for the
>> store or is something related to the uri scheme I am using ?
>> Sorry but I couldn't find more info on this in the sources/docs .
>>
>>
>> thank you
>>
>>
>>
>> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana
>> wrote:
>> >
>> > OK, thank you very much for your comments, that's clear.
>> >
>> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote:
>> >>
>> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already
>> >> modified to use OSSL_STORE API to load keys. So you do not need to
>> >> specify keyform=ENGINE if your key is provided by a provider that
>> >> supports the STORE functionality for some special URL scheme. You just
>> >> specify the right URL with that scheme to reference the key in the
>> >> provider.
>> >>
>> >> Of course third party applications need to be modified to call
>> >> OSSL_STORE API in a similar way how the openssl application does it.
>> >>
>> >> Tomas
>> >>
>> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote:
>> >> > Thank you for your comment.
>> >> > Am I wrong then in saying that dgst and possibly other apps are not
>> >> > ready to be used with providers rather than engines in the case you
>> >> > need keyform=ENGINE ?
>> >> >
>> >> >
>> >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote:
>> >> > > You would have to implement a STORE provider that handles your
>> >> > > special
>> >> > > url scheme and then the keys would be referenced by the
>> >> > > yourscheme://any-identifier-you-have. Of course the application
>> >> > > (i.e.,
>> >> > > the openssl application which already does this) would have to use
>> >> > > the
>> >> > > OSSL_STORE API to load the keys and not directly
Re: Store Mgmt and keys loading ( keyform ENG )
It is because of prototypes of methods..
On Thu, 7 Oct 2021, 08:49 Antonio Santagiuliana,
wrote:
> Hello,
> just continuing on this..
> I defined my store mgmt as :
> static const OSSL_ALGORITHM test_store[] = {
> { "handle", "provider=test", mystore_functions},
> {NULL, NULL, NULL}
> };
>
> echo "test" | LD_LIBRARY_PATH=.apps/openssl dgst
> --provider-path=./providers --provider=test --sign handle:1 -out
> messa.encrypted.bin
>
> Could not open file or uri for loading private key from handle:1
>
> C0628C24787F:error:1669:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=file
>
> C0628C24787F:error:1608010C:STORE
> routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
> store loader found. For standard store loaders you need at least one
> of the default or base providers available. Did you forget to load
> them? Info: Global default library context, Scheme (file : 0),
> Properties ()
>
> C0628C24787F:error:1669:STORE
> routines:ossl_store_get0_loader_int:unregistered
> scheme:crypto/store/store_register.c:237:scheme=handle
>
> 1) It firstly looks for a provider for scheme file: and it doesn't
> find as I haven't set up any store mgmt for file: .
>
> 2) It looks like on second attempt it tries to look for handle: but it
> finds it not registered. What does this error mean ? Does it look for
> registered uri schemes online ? if that is the case how can this works
> instead : https://github.com/tpm2-software/tpm2-openssl ? They use
> handle: scheme as well.
>
> Does this mean it's a problem of the methods I registered for the
> store or is something related to the uri scheme I am using ?
> Sorry but I couldn't find more info on this in the sources/docs .
>
>
> thank you
>
>
>
> On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana
> wrote:
> >
> > OK, thank you very much for your comments, that's clear.
> >
> > On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote:
> >>
> >> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already
> >> modified to use OSSL_STORE API to load keys. So you do not need to
> >> specify keyform=ENGINE if your key is provided by a provider that
> >> supports the STORE functionality for some special URL scheme. You just
> >> specify the right URL with that scheme to reference the key in the
> >> provider.
> >>
> >> Of course third party applications need to be modified to call
> >> OSSL_STORE API in a similar way how the openssl application does it.
> >>
> >> Tomas
> >>
> >> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote:
> >> > Thank you for your comment.
> >> > Am I wrong then in saying that dgst and possibly other apps are not
> >> > ready to be used with providers rather than engines in the case you
> >> > need keyform=ENGINE ?
> >> >
> >> >
> >> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote:
> >> > > You would have to implement a STORE provider that handles your
> >> > > special
> >> > > url scheme and then the keys would be referenced by the
> >> > > yourscheme://any-identifier-you-have. Of course the application
> >> > > (i.e.,
> >> > > the openssl application which already does this) would have to use
> >> > > the
> >> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER
> >> > > API
> >> > > or the d2i/PEM_read APIs.
> >> > >
> >> > > Tomas
> >> > >
> >> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote:
> >> > > > I checked the sources, I found that keyform cannot be set to
> >> > > > ENGINE
> >> > > > if engine is not specified in the command options, this is in the
> >> > > > function make_engine_url() called from load_key() when
> >> > > > format==FORMAT_ENGINE.
> >> > > > I am not specifying engine in the dgst command options as I am
> >> > > using
> >> > > > a provider.
> >> > > > I would like to achieve the same as FORMAT_ENGINE does, but with
> >> > > > provider.
> >> > > >
> >> > > >
> >> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana,
> >> > > > wrote:
> >> > > > > Hello,
> >> > > > > I am doing
Re: Store Mgmt and keys loading ( keyform ENG )
Hello,
just continuing on this..
I defined my store mgmt as :
static const OSSL_ALGORITHM test_store[] = {
{ "handle", "provider=test", mystore_functions},
{NULL, NULL, NULL}
};
echo "test" | LD_LIBRARY_PATH=.apps/openssl dgst
--provider-path=./providers --provider=test --sign handle:1 -out
messa.encrypted.bin
Could not open file or uri for loading private key from handle:1
C0628C24787F:error:1669:STORE
routines:ossl_store_get0_loader_int:unregistered
scheme:crypto/store/store_register.c:237:scheme=file
C0628C24787F:error:1608010C:STORE
routines:inner_loader_fetch:unsupported:crypto/store/store_meth.c:356:No
store loader found. For standard store loaders you need at least one
of the default or base providers available. Did you forget to load
them? Info: Global default library context, Scheme (file : 0),
Properties ()
C0628C24787F:error:1669:STORE
routines:ossl_store_get0_loader_int:unregistered
scheme:crypto/store/store_register.c:237:scheme=handle
1) It firstly looks for a provider for scheme file: and it doesn't
find as I haven't set up any store mgmt for file: .
2) It looks like on second attempt it tries to look for handle: but it
finds it not registered. What does this error mean ? Does it look for
registered uri schemes online ? if that is the case how can this works
instead : https://github.com/tpm2-software/tpm2-openssl ? They use
handle: scheme as well.
Does this mean it's a problem of the methods I registered for the
store or is something related to the uri scheme I am using ?
Sorry but I couldn't find more info on this in the sources/docs .
thank you
On Mon, Oct 4, 2021 at 4:52 PM Antonio Santagiuliana
wrote:
>
> OK, thank you very much for your comments, that's clear.
>
> On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote:
>>
>> No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already
>> modified to use OSSL_STORE API to load keys. So you do not need to
>> specify keyform=ENGINE if your key is provided by a provider that
>> supports the STORE functionality for some special URL scheme. You just
>> specify the right URL with that scheme to reference the key in the
>> provider.
>>
>> Of course third party applications need to be modified to call
>> OSSL_STORE API in a similar way how the openssl application does it.
>>
>> Tomas
>>
>> On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote:
>> > Thank you for your comment.
>> > Am I wrong then in saying that dgst and possibly other apps are not
>> > ready to be used with providers rather than engines in the case you
>> > need keyform=ENGINE ?
>> >
>> >
>> > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote:
>> > > You would have to implement a STORE provider that handles your
>> > > special
>> > > url scheme and then the keys would be referenced by the
>> > > yourscheme://any-identifier-you-have. Of course the application
>> > > (i.e.,
>> > > the openssl application which already does this) would have to use
>> > > the
>> > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER
>> > > API
>> > > or the d2i/PEM_read APIs.
>> > >
>> > > Tomas
>> > >
>> > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote:
>> > > > I checked the sources, I found that keyform cannot be set to
>> > > > ENGINE
>> > > > if engine is not specified in the command options, this is in the
>> > > > function make_engine_url() called from load_key() when
>> > > > format==FORMAT_ENGINE.
>> > > > I am not specifying engine in the dgst command options as I am
>> > > using
>> > > > a provider.
>> > > > I would like to achieve the same as FORMAT_ENGINE does, but with
>> > > > provider.
>> > > >
>> > > >
>> > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana,
>> > > > wrote:
>> > > > > Hello,
>> > > > > I am doing my own provider starting from the default provider's
>> > > > > code.
>> > > > > I have now a question, I am seeing the STOREMGMT operation is
>> > > > > required to interpret the URI of input private key, I would
>> > > > > like
>> > > > > that the string passed by the user for input key is not
>> > > > > interpret
>> > > > > as file to open but just my provider should save the string
>> > > > > value
>> > > > > to be used later .This is when i
Re: Store Mgmt and keys loading ( keyform ENG )
OK, thank you very much for your comments, that's clear. On Mon, 4 Oct 2021, 15:45 Tomas Mraz, wrote: > No, that's wrong. The dgst and other apps in OpenSSL-3.0 were already > modified to use OSSL_STORE API to load keys. So you do not need to > specify keyform=ENGINE if your key is provided by a provider that > supports the STORE functionality for some special URL scheme. You just > specify the right URL with that scheme to reference the key in the > provider. > > Of course third party applications need to be modified to call > OSSL_STORE API in a similar way how the openssl application does it. > > Tomas > > On Mon, 2021-10-04 at 15:39 +0100, Antonio Santagiuliana wrote: > > Thank you for your comment. > > Am I wrong then in saying that dgst and possibly other apps are not > > ready to be used with providers rather than engines in the case you > > need keyform=ENGINE ? > > > > > > On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > > > You would have to implement a STORE provider that handles your > > > special > > > url scheme and then the keys would be referenced by the > > > yourscheme://any-identifier-you-have. Of course the application > > > (i.e., > > > the openssl application which already does this) would have to use > > > the > > > OSSL_STORE API to load the keys and not directly the OSSL_DECODER > > > API > > > or the d2i/PEM_read APIs. > > > > > > Tomas > > > > > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > > > I checked the sources, I found that keyform cannot be set to > > > > ENGINE > > > > if engine is not specified in the command options, this is in the > > > > function make_engine_url() called from load_key() when > > > > format==FORMAT_ENGINE. > > > > I am not specifying engine in the dgst command options as I am > > > using > > > > a provider. > > > > I would like to achieve the same as FORMAT_ENGINE does, but with > > > > provider. > > > > > > > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > > > wrote: > > > > > Hello, > > > > > I am doing my own provider starting from the default provider's > > > > > code. > > > > > I have now a question, I am seeing the STOREMGMT operation is > > > > > required to interpret the URI of input private key, I would > > > > > like > > > > > that the string passed by the user for input key is not > > > > > interpret > > > > > as file to open but just my provider should save the string > > > > > value > > > > > to be used later .This is when invoking command options such > > > > > as > > > > > dgst sign -in "text" -keyform ENG. > > > > > With engines' architecture this is possible by passing option - > > > > > keyform ENG to dgst command. The string in that case is not > > > > > interpreted as a file path and just passed through. > > > > > There was engine_set_load_privkey_function that was getting > > > > > this > > > > > string. > > > > > How can I achieve this now with the provider architecture ? If > > > > > I > > > > > pass -keyform ENG to dgst command together with --provider , it > > > > > says "no engine specified to load private key" Should I use > > > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I > > > don't > > > > > have a real private key info to load and use from a Filesystem. > > > > > Is there anything to set in the KEYMGMT too ? I can see there > > > > > is > > > a > > > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > > > data in a key object should be considered. Not really sure if > > > this > > > > > is something I should set or not and how this keymgmt operation > > > > > relates with storemgmt operation. > > > > > > > > > > thank you if you can send some comment on this. > > > > > > > > > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > >
Re: Store Mgmt and keys loading ( keyform ENG )
Thank you for your comment. Am I wrong then in saying that dgst and possibly other apps are not ready to be used with providers rather than engines in the case you need keyform=ENGINE ? On Mon, 4 Oct 2021, 14:13 Tomas Mraz, wrote: > You would have to implement a STORE provider that handles your special > url scheme and then the keys would be referenced by the > yourscheme://any-identifier-you-have. Of course the application (i.e., > the openssl application which already does this) would have to use the > OSSL_STORE API to load the keys and not directly the OSSL_DECODER API > or the d2i/PEM_read APIs. > > Tomas > > On Mon, 2021-10-04 at 13:56 +0100, Antonio Santagiuliana wrote: > > I checked the sources, I found that keyform cannot be set to ENGINE > > if engine is not specified in the command options, this is in the > > function make_engine_url() called from load_key() when > > format==FORMAT_ENGINE. > > I am not specifying engine in the dgst command options as I am using > > a provider. > > I would like to achieve the same as FORMAT_ENGINE does, but with > > provider. > > > > > > On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, > > wrote: > > > Hello, > > > I am doing my own provider starting from the default provider's > > > code. > > > I have now a question, I am seeing the STOREMGMT operation is > > > required to interpret the URI of input private key, I would like > > > that the string passed by the user for input key is not interpret > > > as file to open but just my provider should save the string value > > > to be used later .This is when invoking command options such as > > > dgst sign -in "text" -keyform ENG. > > > With engines' architecture this is possible by passing option - > > > keyform ENG to dgst command. The string in that case is not > > > interpreted as a file path and just passed through. > > > There was engine_set_load_privkey_function that was getting this > > > string. > > > How can I achieve this now with the provider architecture ? If I > > > pass -keyform ENG to dgst command together with --provider , it > > > says "no engine specified to load private key" Should I use > > > OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . > > > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't > > > have a real private key info to load and use from a Filesystem. > > > Is there anything to set in the KEYMGMT too ? I can see there is a > > > flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key > > > data in a key object should be considered. Not really sure if this > > > is something I should set or not and how this keymgmt operation > > > relates with storemgmt operation. > > > > > > thank you if you can send some comment on this. > > > > > -- > Tomáš Mráz > No matter how far down the wrong road you've gone, turn back. > Turkish proverb > [You'll know whether the road is wrong if you carefully listen to your > conscience.] > > >
Re: Store Mgmt and keys loading ( keyform ENG )
I checked the sources, I found that keyform cannot be set to ENGINE if engine is not specified in the command options, this is in the function make_engine_url() called from load_key() when format==FORMAT_ENGINE. I am not specifying engine in the dgst command options as I am using a provider. I would like to achieve the same as FORMAT_ENGINE does, but with provider. On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, wrote: > Hello, > I am doing my own provider starting from the default provider's code. > I have now a question, I am seeing the STOREMGMT operation is required to > interpret the URI of input private key, I would like that the string > passed by the user for input key is not interpret as file to open but just > my provider should save the string value to be used later .This is when > invoking command options such as dgst sign -in "text" -keyform ENG. > With engines' architecture this is possible by passing option -keyform ENG > to dgst command. The string in that case is not interpreted as a file path > and just passed through. > There was engine_set_load_privkey_function that was getting this string. > How can I achieve this now with the provider architecture ? If I pass > -keyform ENG to dgst command together with --provider , it says "no engine > specified to load private key" Should I use OSSL_FUNC_store_load_fn and > OSSL_FUNC_store_open_fn ? . > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a > real private key info to load and use from a Filesystem. > Is there anything to set in the KEYMGMT too ? I can see there is a flag > OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key > object should be considered. Not really sure if this is something I should > set or not and how this keymgmt operation relates with storemgmt operation. > > thank you if you can send some comment on this. > >
Re: Store Mgmt and keys loading ( keyform ENG )
Forgot to write, I am using Openssl 3.0. Thank you On Mon, 4 Oct 2021, 12:12 Antonio Santagiuliana, wrote: > Hello, > I am doing my own provider starting from the default provider's code. > I have now a question, I am seeing the STOREMGMT operation is required to > interpret the URI of input private key, I would like that the string > passed by the user for input key is not interpret as file to open but just > my provider should save the string value to be used later .This is when > invoking command options such as dgst sign -in "text" -keyform ENG. > With engines' architecture this is possible by passing option -keyform ENG > to dgst command. The string in that case is not interpreted as a file path > and just passed through. > There was engine_set_load_privkey_function that was getting this string. > How can I achieve this now with the provider architecture ? If I pass > -keyform ENG to dgst command together with --provider , it says "no engine > specified to load private key" Should I use OSSL_FUNC_store_load_fn and > OSSL_FUNC_store_open_fn ? . > Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a > real private key info to load and use from a Filesystem. > Is there anything to set in the KEYMGMT too ? I can see there is a flag > OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key > object should be considered. Not really sure if this is something I should > set or not and how this keymgmt operation relates with storemgmt operation. > > thank you if you can send some comment on this. > >
Store Mgmt and keys loading ( keyform ENG )
Hello, I am doing my own provider starting from the default provider's code. I have now a question, I am seeing the STOREMGMT operation is required to interpret the URI of input private key, I would like that the string passed by the user for input key is not interpret as file to open but just my provider should save the string value to be used later .This is when invoking command options such as dgst sign -in "text" -keyform ENG. With engines' architecture this is possible by passing option -keyform ENG to dgst command. The string in that case is not interpreted as a file path and just passed through. There was engine_set_load_privkey_function that was getting this string. How can I achieve this now with the provider architecture ? If I pass -keyform ENG to dgst command together with --provider , it says "no engine specified to load private key" Should I use OSSL_FUNC_store_load_fn and OSSL_FUNC_store_open_fn ? . Also, at low level I am using RSA_FLAG_EXT_PKEY flag set as I don't have a real private key info to load and use from a Filesystem. Is there anything to set in the KEYMGMT too ? I can see there is a flag OSSL_KEYMGMT_SELECT_PRIVATE_KEY indicating the private key data in a key object should be considered. Not really sure if this is something I should set or not and how this keymgmt operation relates with storemgmt operation. thank you if you can send some comment on this.
Re: RSA provider use example
Thank you for your reply. I'm still a bit confused though. In /providers/implementations/asymcipher/rsa_enc.c I find function rsa_decrypt() that calls RSA_private_decrypt(prsactx->rsa) I haven't found other implementation of this RSA_private_decrypt() apart from the one in crypto/RSA/rsa_crypt.c , where the RSA argument passed is used to call this: rsa->meth->rsa_priv_dec() I can't find where this pointer to method was set up. I can't find it in the init of the default provider's rsa_enc.c and if the app requesting this default RSA can't use the set_method() because deprecated, how is this rsa_priv_dec pointer set up?where is the set up of it? Thank you On Fri, 24 Sep 2021, 15:02 Matt Caswell, wrote: > > > On 24/09/2021 14:49, Antonio Santagiuliana wrote: > > Hello , thank you all for the replies. Very useful. > > I have seen in Openssl/crypto/RSA/rsa_local.h the definition of rsa_st > > has a pointer to RSA_METHOD and I can't see this filled in in any of the > > examples' set up or initializations, where is it filled in for the > > default provider , for the RSA algorithm? > > I can see the methods pointers are used later down in the call chain > > from RSA_private_decrypt() in > > providers/implementation/asymciphers/rsa_enc but I can't find where > > these methods' pointers are set and I would like to understand how I > > could pass a different method pointer in the parameters for a different > > mod_exp operation , for example, or how I could set it on a completely > > new RSA implementation mimicking the one in the default provider but > > with different methods where I need them changed, minimizing the > > differences with the default provider's RSA. > > The default RSA_METHOD structure to use can be set via > RSA_set_default_method(): > > https://www.openssl.org/docs/man3.0/man3/RSA_set_default_method.html > > You can construct such an RSA_METHOD using the functions described here: > > https://www.openssl.org/docs/man3.0/man3/RSA_meth_new.html > > However all of the above is considered deprecated and legacy and may be > removed from a future version of OpenSSL. > > Instead you are supposed to implement such things in a new provider. For > example see: > > https://www.openssl.org/docs/man3.0/man7/provider-base.html > https://www.openssl.org/docs/man3.0/man7/provider.html > https://www.openssl.org/docs/man3.0/man7/provider-signature.html > https://www.openssl.org/docs/man3.0/man7/provider-keymgmt.html > > > Matt > > > > Thank you > > > > > > On Fri, 24 Sep 2021, 12:22 Matt Caswell, > <mailto:m...@openssl.org>> wrote: > > > > > > > > On 24/09/2021 12:17, Dr Paul Dale wrote: > > > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > > > 3.0 doesn't use the RSA structure in the non-deprecated public > API. > > > > > > You probably want the EVP_PKEY_fromdata call. > > > > An example of building an RSA key from its constituent parts is > > available on the EVP_PKEY_fromdata() man page: > > > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > <https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html> > > > > Matt > > > > > > > > > > > > > Pauli > > > > > > > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > > >> Hello > > >> Is there any app or command in the current Openssl master > > repository > > >> that initialises and uses the new RSA provider? > > >> I would like to see how the RSA* context parameter is filled in > and > > >> used, but I can't find an example using the RSA provider. > > >> > > >> > > >> Thank you > > >> > > > > > >
Re: RSA provider use example
Hello , thank you all for the replies. Very useful. I have seen in Openssl/crypto/RSA/rsa_local.h the definition of rsa_st has a pointer to RSA_METHOD and I can't see this filled in in any of the examples' set up or initializations, where is it filled in for the default provider , for the RSA algorithm? I can see the methods pointers are used later down in the call chain from RSA_private_decrypt() in providers/implementation/asymciphers/rsa_enc but I can't find where these methods' pointers are set and I would like to understand how I could pass a different method pointer in the parameters for a different mod_exp operation , for example, or how I could set it on a completely new RSA implementation mimicking the one in the default provider but with different methods where I need them changed, minimizing the differences with the default provider's RSA. Thank you On Fri, 24 Sep 2021, 12:22 Matt Caswell, wrote: > > > On 24/09/2021 12:17, Dr Paul Dale wrote: > > What about: apps/rsa.c, apps/rsautl.c and apps/genrsa.c > > 3.0 doesn't use the RSA structure in the non-deprecated public API. > > > > You probably want the EVP_PKEY_fromdata call. > > An example of building an RSA key from its constituent parts is > available on the EVP_PKEY_fromdata() man page: > > https://www.openssl.org/docs/man3.0/man3/EVP_PKEY_fromdata.html > > Matt > > > > > > > > Pauli > > > > > > On 24/9/21 8:55 pm, Antonio Santagiuliana wrote: > >> Hello > >> Is there any app or command in the current Openssl master repository > >> that initialises and uses the new RSA provider? > >> I would like to see how the RSA* context parameter is filled in and > >> used, but I can't find an example using the RSA provider. > >> > >> > >> Thank you > >> > > >
RSA provider use example
Hello Is there any app or command in the current Openssl master repository that initialises and uses the new RSA provider? I would like to see how the RSA* context parameter is filled in and used, but I can't find an example using the RSA provider. Thank you
RSA_METHOD on provider
Hello I was wondering how to migrate to a provider for Openssl 3.0 an engine for openssl 1.0.2 that was simply defining on an RSA_METHOD structure the method for modular exponentiation for RSA and getting call parameters from RSA_get_ex_data(), in order then to use an hw accelerator. Other methods were not re-defined . What should I do for making it a provider to run with Openssl 3.0? I cannot find this in the list of possible operations. Thank you Antonio
[no subject]
Hello I was wondering how to migrate to a provider for Openssl 3.0 an engine for openssl 1.0.2 that was simply defining on an RSA_METHOD structure the method for modular exponentiation for RSA and getting call parameters from RSA_get_ex_data(), in order then to use an hw accelerator. Other methods were not re-defined . What should I do for making it a provider to run with Openssl 3.0? I cannot find this in the list of possible operations. Thank you Antonio
