Am 27.02.17 um 16:33 schrieb Dr. Stephen Henson:
On Mon, Feb 27, 2017, Stephan M?hlstrasser wrote:
Am 27.02.17 um 15:34 schrieb Dr. Stephen Henson:
There shouldn't be any need to add the method to the list: it should be
possible to associate an EVP_PKEY with a non-default method (e.g. explicitly
or implemented in an ENGINE). I say *should* because there doesn't seem to be
currently a way to do that without changing EVP_PKEY internal fields (which
isn't possible in 1.1.0 anyway).
I'm sorry, I don't get what you are trying to tell me in the above
paragraph. Are you talking about an alternative way to set up the
methods in the EVP_PKEY_METHOD structure?
Well this is by analogy with how the other algorithm specific methods work.
With RSA_METHOD et al there are two ways to provide your own mechanisms for
operations.
If it's a general purpose mechanism (e.g. a crypto accelerator) which should
perform all RSA operations you can provide the default method.
If you want to only affect certain keys (e.g. those tied to a specific HSM)
you *can* do this via the default method and just check each key as it goes
through (e.g. some ex_data attached to it) and only handle those of interest
passing the rest to the default operation.
There is an alternative way. You create a custom method and set that as the
key's internal method. Then any existing keys use the default method as usual
but the keys you care about go through the custom method.
For EVP_PKEY_METHOD you can provide the default implementation for an
algorithm but unfortunately there is no way to provide a key specific method
which is transparently used.
Ok, thank you for this explanation! I will try to make sense of this and
I will see whether I am able to map this to the corresponding API calls
and data structures...
--
Stephan
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users