Geoff Thorpe wrote:
>
> On Sat, 25 Nov 2000, Dr S N Henson wrote:
>
> > An application could always use the ex_data callback new_func() to do
> > the initialization.
>
> Not really, because you'd need to wait until the CRYPTO_EX_DATA structure
> had actually been initialised (which is after init() gets called) before
> setting the callback. In other words, you can't override behaviour simply
> by implementing an RSA_METHOD, you need to hack the calling application
> itself. Kind of defeats the purpose.
>
Eh? I'm talking here about the new_func() callback set up with
RSA_get_ex_new_index(). An application using ex_data would want a new
unique index. new_func() would get called during the initialisation of
the ex_data and would get passed a pointer to the parent RSA structure
and a few other things. It should then be able to modify ex_data based
on the parent RSA structure.
>
> No, but the RSA_METHOD that the RSA structure will use *has* been
> established at that point, so it's a good point to try and create and
> store anything needed by the RSA_METHOD for operating on that RSA
> structure. The reason I want to do this is to duplicate a "handle" (of
> sorts) with reference counting - by adding such a reference to each key in
> the init() handler and releasing it in the finish() handler it would work
> cleanly. Basically, I want to avoid "run-time" operations having to
> continually run those "initialise a context if it hasn't been done yet"
> checks before trying to use a context. Otherwise init() has absolutely no
> possible usefulness that I can see (even the flags don't need an init()
> handler to set them, because the RSA_METHOD has a flags value).
>
The only potential problem with that is that an RSA structure can be
created and no actual crypto done with it which is why some of the
internal code does things on the first use, albeit rather badly.
I agree that init() isn't particularly useful. It would be much better
if it, or an equivalent, was called when the RSA structure contained
more useful info.
Steve.
--
Dr Stephen N. Henson. http://www.drh-consultancy.demon.co.uk/
Personal Email: [EMAIL PROTECTED]
Senior crypto engineer, Celo Communications: http://www.celocom.com/
Core developer of the OpenSSL project: http://www.openssl.org/
Business Email: [EMAIL PROTECTED] PGP key: via homepage.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
