Hi there,
On Mon, 18 Sep 2000, Ben Laurie wrote:
> I've had some time to start looking at the engine code, and the first
> thing I notice is that the various engines fill in the functions they
> don't provide by getting hold of the "standard" engine, and copying them
> across. It seems to me that this isn't very future-proof - what we
It's deliberately done that way because in the specific cases, it is known
that the functions in rsa_eay.c, dsa_ossl.c, etc behave in exactly the way
expected so that the minimal hardware-specific code is hooked in the
correct way. The code is written that way not so as to "inherit default
behaviour" but because the ENGINE_openssl() functions do exactly what is
required to intermingle with the hardware-specific functions. It is not
because the hardware-specific functions wish to intermingle with "default"
functions at all.
> really want is for there to be a way to get hold of an engine structure,
> pre-filled with the defaults, and then override the stuff we are
Nope, because some engines will not populate or use the key structures in
the same way as others (think hardware key-management). Also, an ENGINE
that does not implement DSA (for example) should not populate the
DSA_METHOD ... for example see the code for ENGINE_set_default(). Having
said that, I may have violated the concept myself once or twice ... time
to audit my own code me thinks ... :-)
Anyway, the intention thus far has been to amalgamate implemented
algorithms, hopefully by an EVP_*** style encapsulation. The point being
that it's not just a question of "which of RSA,DSA,DH,BN,RAND does it
implement?" ... but also whether or not the specific engine can add new
algorithms. Pre-populating an ENGINE structure with defaults would
somewhat defeat the purpose of the abstraction - an ENGINE could simply
support random number generation and plug itself into the list - the
library (and its caller) are then free to try and utilise it if they wish
to do whatever the engine is capable of doing. The library right now would
prevent you from assigning that new engine to do anything other than
random number generation. Eventuallly we hope that an engine could also
just implement only new algorithms, thus supplementing what's already
available. It would thus be completely counter-intuitive to say such an
engine supports RSA too by populating its RSA_METHOD pointer with the
inherited "default".
You'll also notice that it's deliberately possible right now to have
different ENGINEs set as defaults for different algorithms (eg. set an
nCipher unit doing RAND, an atalla card doing bn_mod_exp, a cryptoswift
doing DSA, etc.)
> interested in, surely? This is particularly important if we ever hope to
> have upward binary compatibility.
hehe ... there's a few other major nitpicks to address before binary
compatibility can be hoped for. Eg. to load an ENGINE from a DSO
completely, handlers need to be passed to the shared library to let it
callback into OpenSSL where it needs (rather than resorting to the loader
binding the required symbols which is evil, confusing, often ambiguous
and/or conflicting, error-prone, and disastrous for binary compatibility).
Eg. how do you hand a shared library a "pointer to the bignum functions"??
This is next to impossible right now, let alone how to do it in a upwards
and backwards compatible way. A BN_METHOD is currently completely
undoable. Anyway, this *also* begs the question of algorithm encapsulation
so that we don't have discrete structures etc for RSA, DSA, et al. The
encapsulation needs to remain functional and not structural (as the ENGINE
currently is) if we want binary compatibility, and this poses a major
problem for much of the library which not only depends on exposing the
structure definitions to external code, but often exposes macros that
operate on them too, and exposes millions of little structures and
functions everywhere which makes function tables next to impossible to
construct.
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
