connection specific data in sign provider

[Richard Levitte]

That statement a bit taoo categorical.  We actually do something like
that in OpenSSL, and it's even documented.

See doc/man7/provider-object.pod, and its history in the git commit log.

That being said, you must be very careful when playing this sort of
game, so the statement definitely serves as a (strong) warning.

Cheers,
Richard

Dr Paul Dale <pauli at openssl.org> writes:

> Absolutely do not even consider doing a hack like this.
> Never pass a pointer as an octet string.
> Ever.
>
>
> Pauli
>
> On 13/11/23 19:08, Tomas Mraz wrote:
>> You would have to pass the callback pointer as an octet string
>> OSSL_PARAM set on the signature context. That would of course require
>> patching libssl to set the pointer on the signature context when it is
>> invoking the signature.
>>
>> The providers do not have direct reach to libssl or libcrypto data.
>>
>> Tomas Mraz, OpenSSL
>>
>> On Sat, 2023-11-11 at 12:48 +0000, boknamail via openssl-users wrote:
>>> Hi all,
>>>
>>> I implemented an Openssl signature provider that shall offload the
>>> signature into the user's code space via a callback that the user can
>>> define.
>>> During the TLS handshake I already get the function
>>> OSSL_FUNC_signature_digest_sign invoked. Inside this function I want
>>> to call the user defined callback.
>>>
>>> My current approach is to create a provider context containing an
>>> empty callback, have the user get the provider context and set the
>>> callback and inside OSSL_FUNC_signature_digest_sign_init copy the
>>> callback from the provider context into the sign context.
>>>
>>> The disadvantage of this is, that the callback is global to the
>>> provider.
>>> I would rather want to have it connection specific.
>>> Is there any way to handover data specific to the connection to the
>>> sign functions?
>>> I was thinking about adding the callback to the ex_data of the
>>> SSL_CTX, but did not find a way to access the SSL_CTX or the SSL from
>>> inside the signature function.
>>>
>>> Thanks!
>>>
>

-- 
-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/