6 files changed, 697 insertions, 466 deletions

diff --git a/src/lib/libcrypto/engine/README b/src/lib/libcrypto/engine/README
index 96595e6f35..6b69b70f57 100644
--- a/src/lib/libcrypto/engine/README
+++ b/src/lib/libcrypto/engine/README
@@ -1,278 +1,211 @@
-NOTES, THOUGHTS, and EVERYTHING
--------------------------------
-
-(1) Concurrency and locking ... I made a change to the ENGINE_free code
-    because I spotted a potential hold-up in proceedings (doing too
-    much inside a lock including calling a callback), there may be
-    other bits like this. What do the speed/optimisation freaks think
-    of this aspect of the code and design? There's lots of locking for
-    manipulation functions and I need that to keep things nice and
-    solid, but this manipulation is mostly (de)initialisation, I would
-    think that most run-time locking is purely in the ENGINE_init and
-    ENGINE_finish calls that might be made when getting handles for
-    RSA (and friends') structures. These would be mostly reference
-    count operations as the functional references should always be 1
-    or greater at run-time to prevent init/deinit thrashing.
-
-(2) nCipher support, via the HWCryptoHook API, is now in the code.
-    Apparently this hasn't been tested too much yet, but it looks
-    good. :-) Atalla support has been added too, but shares a lot in
-    common with Ben's original hooks in bn_exp.c (although it has been
-    ENGINE-ified, and error handling wrapped around it) and it's also
-    had some low-volume testing, so it should be usable.
-
-(3) Of more concern, we need to work out (a) how to put together usable
-    RAND_METHODs for units that just have one "get n or less random
-    bytes" function, (b) we also need to determine how to hook the code
-    in crypto/rand/ to use the ENGINE defaults in a way similar to what
-    has been done in crypto/rsa/, crypto/dsa/, etc.
-
-(4) ENGINE should really grow to encompass more than 3 public key
-    algorithms and randomness gathering. The structure/data level of
-    the engine code is hidden from code outside the crypto/engine/
-    directory so change shouldn't be too viral. More important though
-    is how things should evolve ... this needs thought and discussion.
-
-
------------------------------------==*==-----------------------------------
-
-More notes 2000-08-01
----------------------
-
-Geoff Thorpe, who designed the engine part, wrote a pretty good description
-of the thoughts he had when he built it, good enough to include verbatim here
-(with his permission)                                   -- Richard Levitte
-
-
-Date: Tue, 1 Aug 2000 16:54:08 +0100 (BST)
-From: Geoff Thorpe
-Subject: Re: The thoughts to merge BRANCH_engine into the main trunk are
- emerging
-
-Hi there,
-
-I'm going to try and do some justice to this, but I'm a little short on
-time and the there is an endless amount that could be discussed on this
-subject. sigh ... please bear with me :-)
-
-> The changes in BRANCH_engine dig deep into the core of OpenSSL, for example
-> into the RSA and RAND routines, adding a level of indirection which is needed
-> to keep the abstraction, as far as I understand.  It would be a good thing if
-> those who do play with those things took a look at the changes that have been
-> done in the branch and say out loud how much (or hopefully little) we've made
-> fools of ourselves.
-
-The point here is that the code that has emerged in the BRANCH_engine
-branch was based on some initial requirements of mine that I went in and
-addressed, and Richard has picked up the ball and run with it too. It
-would be really useful to get some review of the approach we've taken, but
-first I think I need to describe as best I can the reasons behind what has
-been done so far, in particular what issues we have tried to address when
-doing this, and what issues we have intentionally (or necessarily) tried
-to avoid.
-
-methods, engines, and evps
---------------------------
-
-There has been some dicussion, particularly with Steve, about where this
-ENGINE stuff might fit into the conceptual picture as/when we start to
-abstract algorithms a little bit to make the library more extensible. In
-particular, it would desirable to have algorithms (symmetric, hash, pkc,
-etc) abstracted in some way that allows them to be just objects sitting in
-a list (or database) ... it'll just happen that the "DSA" object doesn't
-support encryption whereas the "RSA" object does. This requires a lot of
-consideration to begin to know how to tackle it; in particular how
-encapsulated should these things be? If the objects also understand their
-own ASN1 encodings and what-not, then it would for example be possible to
-add support for elliptic-curve DSA in as a new algorithm and automatically
-have ECC-DSA certificates supported in SSL applications. Possible, but not
-easy. :-)
-
-Whatever, it seems that the way to go (if I've grok'd Steve's comments on
-this in the past) is to amalgamate these things in EVP as is already done
-(I think) for ciphers or hashes (Steve, please correct/elaborate). I
-certainly think something should be done in this direction because right
-now we have different source directories, types, functions, and methods
-for each algorithm - even when conceptually they are very much different
-feathers of the same bird. (This is certainly all true for the public-key
-stuff, and may be partially true for the other parts.)
-
-ENGINE was *not* conceived as a way of solving this, far from it. Nor was
-it conceived as a way of replacing the various "***_METHOD"s. It was
-conceived as an abstraction of a sort of "virtual crypto device". If we
-lived in a world where "EVP_ALGO"s (or something like them) encapsulated
-particular algorithms like RSA,DSA,MD5,RC4,etc, and "***_METHOD"s
-encapsulated interfaces to algorithms (eg. some algo's might support a
-PKC_METHOD, a HASH_METHOD, or a CIPHER_METHOD, who knows?), then I would
-think that ENGINE would encapsulate an implementation of arbitrarily many
-of those algorithms - perhaps as alternatives to existing algorithms
-and/or perhaps as new previously unimplemented algorithms. An ENGINE could
-be used to contain an alternative software implementation, a wrapper for a
-hardware acceleration and/or key-management unit, a comms-wrapper for
-distributing cryptographic operations to remote machines, or any other
-"devices" your imagination can dream up.
-
-However, what has been done in the ENGINE branch so far is nothing more
-than starting to get our toes wet. I had a couple of self-imposed
-requirements when putting the initial abstraction together, and I may have
-already posed these in one form or another on the list, but briefly;
-
-   (i) only bother with public key algorithms for now, and maybe RAND too
-       (motivated by the need to get hardware support going and the fact
-       this was a comparitively easy subset to address to begin with).
-
-  (ii) don't change (if at all possible) the existing crypto code, ie. the
-       implementations, the way the ***_METHODs work, etc.
-
- (iii) ensure that if no function from the ENGINE code is ever called then
-       things work the way they always did, and there is no memory
-       allocation (otherwise the failure to cleanup would be a problem -
-       this is part of the reason no STACKs were used, the other part of
-       the reason being I found them inappropriate).
-
-  (iv) ensure that all the built-in crypto was encapsulated by one of
-       these "ENGINE"s and that this engine was automatically selected as
-       the default.
-
-   (v) provide the minimum hooking possible in the existing crypto code
-       so that global functions (eg. RSA_public_encrypt) do not need any
-       extra parameter, yet will use whatever the current default ENGINE
-       for that RSA key is, and that the default can be set "per-key"
-       and globally (new keys will assume the global default, and keys
-       without their own default will be operated on using the global
-       default). NB: Try and make (v) conflict as little as possible with
-       (ii). :-)
-
-  (vi) wrap the ENGINE code up in duct tape so you can't even see the
-       corners. Ie. expose no structures at all, just black-box pointers.
-
-   (v) maintain internally a list of ENGINEs on which a calling
-       application can iterate, interrogate, etc. Allow a calling
-       application to hook in new ENGINEs, remove ENGINEs from the list,
-       and enforce uniqueness within the global list of each ENGINE's
-       "unique id".
-
-  (vi) keep reference counts for everything - eg. this includes storing a
-       reference inside each RSA structure to the ENGINE that it uses.
-       This is freed when the RSA structure is destroyed, or has its
-       ENGINE explicitly changed. The net effect needs to be that at any
-       time, it is deterministic to know whether an ENGINE is in use or
-       can be safely removed (or unloaded in the case of the other type
-       of reference) without invalidating function pointers that may or
-       may not be used indavertently in the future. This was actually
-       one of the biggest problems to overcome in the existing OpenSSL
-       code - implementations had always been assumed to be ever-present,
-       so there was no trivial way to get round this.
-
- (vii) distinguish between structural references and functional
-       references.
-
-A *little* detail
+Notes: 2001-09-24
 -----------------
 
-While my mind is on it; I'll illustrate the bit in item (vii). This idea
-turned out to be very handy - the ENGINEs themselves need to be operated
-on and manipulated simply as objects without necessarily trying to
-"enable" them for use. Eg. most host machines will not have the necessary
-hardware or software to support all the engines one might compile into
-OpenSSL, yet it needs to be possible to iterate across the ENGINEs,
-querying their names, properties, etc - all happening in a thread-safe
-manner that uses reference counts (if you imagine two threads iterating
-through a list and one thread removing the ENGINE the other is currently
-looking at - you can see the gotcha waiting to happen). For all of this,
-*structural references* are used and operate much like the other reference
-counts in OpenSSL.
-
-The other kind of reference count is for *functional* references - these
-indicate a reference on which the caller can actually assume the
-particular ENGINE to be initialised and usable to perform the operations
-it implements. Any increment or decrement of the functional reference
-count automatically invokes a corresponding change in the structural
-reference count, as it is fairly obvious that a functional reference is a
-restricted case of a structural reference. So struct_ref >= funct_ref at
-all times. NB: functional references are usually obtained by a call to
-ENGINE_init(), but can also be created implicitly by calls that require a
-new functional reference to be created, eg. ENGINE_set_default(). Either
-way the only time the underlying ENGINE's "init" function is really called
-is when the (functional) reference count increases to 1, similarly the
-underlying "finish" handler is only called as the count goes down to 0.
-The effect of this, for example, is that if you set the default ENGINE for
-RSA operations to be "cswift", then its functional reference count will
-already be at least 1 so the CryptoSwift shared-library and the card will
-stay loaded and initialised until such time as all RSA keys using the
-cswift ENGINE are changed or destroyed and the default ENGINE for RSA
-operations has been changed. This prevents repeated thrashing of init and
-finish handling if the count keeps getting down as far as zero.
-
-Otherwise, the way the ENGINE code has been put together I think pretty
-much reflects the above points. The reason for the ENGINE structure having
-individual RSA_METHOD, DSA_METHOD, etc pointers is simply that it was the
-easiest way to go about things for now, to hook it all into the raw
-RSA,DSA,etc code, and I was trying to the keep the structure invisible
-anyway so that the way this is internally managed could be easily changed
-later on when we start to work out what's to be done about these other
-abstractions.
-
-Down the line, if some EVP-based technique emerges for adequately
-encapsulating algorithms and all their various bits and pieces, then I can
-imagine that "ENGINE" would turn into a reference-counting database of
-these EVP things, of which the default "openssl" ENGINE would be the
-library's own object database of pre-built software implemented algorithms
-(and such). It would also be cool to see the idea of "METHOD"s detached
-from the algorithms themselves ... so RSA, DSA, ElGamal, etc can all
-expose essentially the same METHOD (aka interface), which would include
-any querying/flagging stuff to identify what the algorithm can/can't do,
-its name, and other stuff like max/min block sizes, key sizes, etc. This
-would result in ENGINE similarly detaching its internal database of
-algorithm implementations from the function definitions that return
-interfaces to them. I think ...
-
-As for DSOs etc. Well the DSO code is pretty handy (but could be made much
-more so) for loading vendor's driver-libraries and talking to them in some
-generic way, but right now there's still big problems associated with
-actually putting OpenSSL code (ie. new ENGINEs, or anything else for that
-matter) in dynamically loadable libraries. These problems won't go away in
-a hurry so I don't think we should expect to have any kind of
-shared-library extensions any time soon - but solving the problems is a
-good thing to aim for, and would as a side-effect probably help make
-OpenSSL more usable as a shared-library itself (looking at the things
-needed to do this will show you why).
-
-One of the problems is that if you look at any of the ENGINE
-implementations, eg. hw_cswift.c or hw_ncipher.c, you'll see how it needs
-a variety of functionality and definitions from various areas of OpenSSL,
-including crypto/bn/, crypto/err/, crypto/ itself (locking for example),
-crypto/dso/, crypto/engine/, crypto/rsa, etc etc etc. So if similar code
-were to be suctioned off into shared libraries, the shared libraries would
-either have to duplicate all the definitions and code and avoid loader
-conflicts, or OpenSSL would have to somehow expose all that functionality
-to the shared-library. If this isn't a big enough problem, the issue of
-binary compatibility will be - anyone writing Apache modules can tell you
-that (Ralf? Ben? :-). However, I don't think OpenSSL would need to be
-quite so forgiving as Apache should be, so OpenSSL could simply tell its
-version to the DSO and leave the DSO with the problem of deciding whether
-to proceed or bail out for fear of binary incompatibilities.
-
-Certainly one thing that would go a long way to addressing this is to
-embark on a bit of an opaqueness mission. I've set the ENGINE code up with
-this in mind - it's so draconian that even to declare your own ENGINE, you
-have to get the engine code to create the underlying ENGINE structure, and
-then feed in the new ENGINE's function/method pointers through various
-"set" functions. The more of the code that takes on such a black-box
-approach, the more of the code that will be (a) easy to expose to shared
-libraries that need it, and (b) easy to expose to applications wanting to
-use OpenSSL itself as a shared-library. From my own explorations in
-OpenSSL, the biggest leviathan I've seen that is a problem in this respect
-is the BIGNUM code. Trying to "expose" the bignum code through any kind of
-organised "METHODs", let alone do all the necessary bignum operations
-solely through functions rather than direct access to the structures and
-macros, will be a massive pain in the "r"s.
-
-Anyway, I'm done for now - hope it was readable. Thoughts?
-
-Cheers,
-Geoff
-
-
------------------------------------==*==-----------------------------------
+This "description" (if one chooses to call it that) needed some major updating
+so here goes. This update addresses a change being made at the same time to
+OpenSSL, and it pretty much completely restructures the underlying mechanics of
+the "ENGINE" code. So it serves a double purpose of being a "ENGINE internals
+for masochists" document *and* a rather extensive commit log message. (I'd get
+lynched for sticking all this in CHANGES or the commit mails :-).
+
+ENGINE_TABLE underlies this restructuring, as described in the internal header
+"eng_int.h", implemented in eng_table.c, and used in each of the "class" files;
+tb_rsa.c, tb_dsa.c, etc.
+
+However, "EVP_CIPHER" underlies the motivation and design of ENGINE_TABLE so
+I'll mention a bit about that first. EVP_CIPHER (and most of this applies
+equally to EVP_MD for digests) is both a "method" and a algorithm/mode
+identifier that, in the current API, "lingers". These cipher description +
+implementation structures can be defined or obtained directly by applications,
+or can be loaded "en masse" into EVP storage so that they can be catalogued and
+searched in various ways, ie. two ways of encrypting with the "des_cbc"
+algorithm/mode pair are;
+
+(i) directly;
+     const EVP_CIPHER *cipher = EVP_des_cbc();
+     EVP_EncryptInit(&ctx, cipher, key, iv);
+     [ ... use EVP_EncryptUpdate() and EVP_EncryptFinal() ...]
+
+(ii) indirectly; 
+     OpenSSL_add_all_ciphers();
+     cipher = EVP_get_cipherbyname("des_cbc");
+     EVP_EncryptInit(&ctx, cipher, key, iv);
+     [ ... etc ... ]
+
+The latter is more generally used because it also allows ciphers/digests to be
+looked up based on other identifiers which can be useful for automatic cipher
+selection, eg. in SSL/TLS, or by user-controllable configuration.
+
+The important point about this is that EVP_CIPHER definitions and structures are
+passed around with impunity and there is no safe way, without requiring massive
+rewrites of many applications, to assume that EVP_CIPHERs can be reference
+counted. One an EVP_CIPHER is exposed to the caller, neither it nor anything it
+comes from can "safely" be destroyed. Unless of course the way of getting to
+such ciphers is via entirely distinct API calls that didn't exist before.
+However existing API usage cannot be made to understand when an EVP_CIPHER
+pointer, that has been passed to the caller, is no longer being used.
+
+The other problem with the existing API w.r.t. to hooking EVP_CIPHER support
+into ENGINE is storage - the OBJ_NAME-based storage used by EVP to register
+ciphers simultaneously registers cipher *types* and cipher *implementations* -
+they are effectively the same thing, an "EVP_CIPHER" pointer. The problem with
+hooking in ENGINEs is that multiple ENGINEs may implement the same ciphers. The
+solution is necessarily that ENGINE-provided ciphers simply are not registered,
+stored, or exposed to the caller in the same manner as existing ciphers. This is
+especially necessary considering the fact ENGINE uses reference counts to allow
+for cleanup, modularity, and DSO support - yet EVP_CIPHERs, as exposed to
+callers in the current API, support no such controls.
+
+Another sticking point for integrating cipher support into ENGINE is linkage.
+Already there is a problem with the way ENGINE supports RSA, DSA, etc whereby
+they are available *because* they're part of a giant ENGINE called "openssl".
+Ie. all implementations *have* to come from an ENGINE, but we get round that by
+having a giant ENGINE with all the software support encapsulated. This creates
+linker hassles if nothing else - linking a 1-line application that calls 2 basic
+RSA functions (eg. "RSA_free(RSA_new());") will result in large quantities of
+ENGINE code being linked in *and* because of that DSA, DH, and RAND also. If we
+continue with this approach for EVP_CIPHER support (even if it *was* possible)
+we would lose our ability to link selectively by selectively loading certain
+implementations of certain functionality. Touching any part of any kind of
+crypto would result in massive static linkage of everything else. So the
+solution is to change the way ENGINE feeds existing "classes", ie. how the
+hooking to ENGINE works from RSA, DSA, DH, RAND, as well as adding new hooking
+for EVP_CIPHER, and EVP_MD.
+
+The way this is now being done is by mostly reverting back to how things used to
+work prior to ENGINE :-). Ie. RSA now has a "RSA_METHOD" pointer again - this
+was previously replaced by an "ENGINE" pointer and all RSA code that required
+the RSA_METHOD would call ENGINE_get_RSA() each time on its ENGINE handle to
+temporarily get and use the ENGINE's RSA implementation. Apart from being more
+efficient, switching back to each RSA having an RSA_METHOD pointer also allows
+us to conceivably operate with *no* ENGINE. As we'll see, this removes any need
+for a fallback ENGINE that encapsulates default implementations - we can simply
+have our RSA structure pointing its RSA_METHOD pointer to the software
+implementation and have its ENGINE pointer set to NULL.
+
+A look at the EVP_CIPHER hooking is most explanatory, the RSA, DSA (etc) cases
+turn out to be degenerate forms of the same thing. The EVP storage of ciphers,
+and the existing EVP API functions that return "software" implementations and
+descriptions remain untouched. However, the storage takes more meaning in terms
+of "cipher description" and less meaning in terms of "implementation". When an
+EVP_CIPHER_CTX is actually initialised with an EVP_CIPHER method and is about to
+begin en/decryption, the hooking to ENGINE comes into play. What happens is that
+cipher-specific ENGINE code is asked for an ENGINE pointer (a functional
+reference) for any ENGINE that is registered to perform the algo/mode that the
+provided EVP_CIPHER structure represents. Under normal circumstances, that
+ENGINE code will return NULL because no ENGINEs will have had any cipher
+implementations *registered*. As such, a NULL ENGINE pointer is stored in the
+EVP_CIPHER_CTX context, and the EVP_CIPHER structure is left hooked into the
+context and so is used as the implementation. Pretty much how things work now
+except we'd have a redundant ENGINE pointer set to NULL and doing nothing.
+
+Conversely, if an ENGINE *has* been registered to perform the algorithm/mode
+combination represented by the provided EVP_CIPHER, then a functional reference
+to that ENGINE will be returned to the EVP_CIPHER_CTX during initialisation.
+That functional reference will be stored in the context (and released on
+cleanup) - and having that reference provides a *safe* way to use an EVP_CIPHER
+definition that is private to the ENGINE. Ie. the EVP_CIPHER provided by the
+application will actually be replaced by an EVP_CIPHER from the registered
+ENGINE - it will support the same algorithm/mode as the original but will be a
+completely different implementation. Because this EVP_CIPHER isn't stored in the
+EVP storage, nor is it returned to applications from traditional API functions,
+there is no associated problem with it not having reference counts. And of
+course, when one of these "private" cipher implementations is hooked into
+EVP_CIPHER_CTX, it is done whilst the EVP_CIPHER_CTX holds a functional
+reference to the ENGINE that owns it, thus the use of the ENGINE's EVP_CIPHER is
+safe.
+
+The "cipher-specific ENGINE code" I mentioned is implemented in tb_cipher.c but
+in essence it is simply an instantiation of "ENGINE_TABLE" code for use by
+EVP_CIPHER code. tb_digest.c is virtually identical but, of course, it is for
+use by EVP_MD code. Ditto for tb_rsa.c, tb_dsa.c, etc. These instantiations of
+ENGINE_TABLE essentially provide linker-separation of the classes so that even
+if ENGINEs implement *all* possible algorithms, an application using only
+EVP_CIPHER code will link at most code relating to EVP_CIPHER, tb_cipher.c, core
+ENGINE code that is independant of class, and of course the ENGINE
+implementation that the application loaded. It will *not* however link any
+class-specific ENGINE code for digests, RSA, etc nor will it bleed over into
+other APIs, such as the RSA/DSA/etc library code.
+
+ENGINE_TABLE is a little more complicated than may seem necessary but this is
+mostly to avoid a lot of "init()"-thrashing on ENGINEs (that may have to load
+DSOs, and other expensive setup that shouldn't be thrashed unnecessarily) *and*
+to duplicate "default" behaviour. Basically an ENGINE_TABLE instantiation, for
+example tb_cipher.c, implements a hash-table keyed by integer "nid" values.
+These nids provide the uniquenness of an algorithm/mode - and each nid will hash
+to a potentially NULL "ENGINE_PILE". An ENGINE_PILE is essentially a list of
+pointers to ENGINEs that implement that particular 'nid'. Each "pile" uses some
+caching tricks such that requests on that 'nid' will be cached and all future
+requests will return immediately (well, at least with minimal operation) unless
+a change is made to the pile, eg. perhaps an ENGINE was unloaded. The reason is
+that an application could have support for 10 ENGINEs statically linked
+in, and the machine in question may not have any of the hardware those 10
+ENGINEs support. If each of those ENGINEs has a "des_cbc" implementation, we
+want to avoid every EVP_CIPHER_CTX setup from trying (and failing) to initialise
+each of those 10 ENGINEs. Instead, the first such request will try to do that
+and will either return (and cache) a NULL ENGINE pointer or will return a
+functional reference to the first that successfully initialised. In the latter
+case it will also cache an extra functional reference to the ENGINE as a
+"default" for that 'nid'. The caching is acknowledged by a 'uptodate' variable
+that is unset only if un/registration takes place on that pile. Ie. if
+implementations of "des_cbc" are added or removed. This behaviour can be
+tweaked; the ENGINE_TABLE_FLAG_NOINIT value can be passed to
+ENGINE_set_table_flags(), in which case the only ENGINEs that tb_cipher.c will
+try to initialise from the "pile" will be those that are already initialised
+(ie. it's simply an increment of the functional reference count, and no real
+"initialisation" will take place).
+
+RSA, DSA, DH, and RAND all have their own ENGINE_TABLE code as well, and the
+difference is that they all use an implicit 'nid' of 1. Whereas EVP_CIPHERs are
+actually qualitatively different depending on 'nid' (the "des_cbc" EVP_CIPHER is
+not an interoperable implementation of "aes_256_cbc"), RSA_METHODs are
+necessarily interoperable and don't have different flavours, only different
+implementations. In other words, the ENGINE_TABLE for RSA will either be empty,
+or will have a single ENGING_PILE hashed to by the 'nid' 1 and that pile
+represents ENGINEs that implement the single "type" of RSA there is.
+
+Cleanup - the registration and unregistration may pose questions about how
+cleanup works with the ENGINE_PILE doing all this caching nonsense (ie. when the
+application or EVP_CIPHER code releases its last reference to an ENGINE, the
+ENGINE_PILE code may still have references and thus those ENGINEs will stay
+hooked in forever). The way this is handled is via "unregistration". With these
+new ENGINE changes, an abstract ENGINE can be loaded and initialised, but that
+is an algorithm-agnostic process. Even if initialised, it will not have
+registered any of its implementations (to do so would link all class "table"
+code despite the fact the application may use only ciphers, for example). This
+is deliberately a distinct step. Moreover, registration and unregistration has
+nothing to do with whether an ENGINE is *functional* or not (ie. you can even
+register an ENGINE and its implementations without it being operational, you may
+not even have the drivers to make it operate). What actually happens with
+respect to cleanup is managed inside eng_lib.c with the "engine_cleanup_***"
+functions. These functions are internal-only and each part of ENGINE code that
+could require cleanup will, upon performing its first allocation, register a
+callback with the "engine_cleanup" code. The other part of this that makes it
+tick is that the ENGINE_TABLE instantiations (tb_***.c) use NULL as their
+initialised state. So if RSA code asks for an ENGINE and no ENGINE has
+registered an implementation, the code will simply return NULL and the tb_rsa.c
+state will be unchanged. Thus, no cleanup is required unless registration takes
+place. ENGINE_cleanup() will simply iterate across a list of registered cleanup
+callbacks calling each in turn, and will then internally delete its own storage
+(a STACK). When a cleanup callback is next registered (eg. if the cleanup() is
+part of a gracefull restart and the application wants to cleanup all state then
+start again), the internal STACK storage will be freshly allocated. This is much
+the same as the situation in the ENGINE_TABLE instantiations ... NULL is the
+initialised state, so only modification operations (not queries) will cause that
+code to have to register a cleanup.
+
+What else? The bignum callbacks and associated ENGINE functions have been
+removed for two obvious reasons; (i) there was no way to generalise them to the
+mechanism now used by RSA/DSA/..., because there's no such thing as a BIGNUM
+method, and (ii) because of (i), there was no meaningful way for library or
+application code to automatically hook and use ENGINE supplied bignum functions
+anyway. Also, ENGINE_cpy() has been removed (although an internal-only version
+exists) - the idea of providing an ENGINE_cpy() function probably wasn't a good
+one and now certainly doesn't make sense in any generalised way. Some of the
+RSA, DSA, DH, and RAND functions that were fiddled during the original ENGINE
+changes have now, as a consequence, been reverted back. This is because the
+hooking of ENGINE is now automatic (and passive, it can interally use a NULL
+ENGINE pointer to simply ignore ENGINE from then on).
+
+Hell, that should be enough for now ... comments welcome: geoff@openssl.org
 
diff --git a/src/lib/libcrypto/engine/eng_all.c b/src/lib/libcrypto/engine/eng_all.c
index a35b3db9e8..b3030fe505 100644
--- a/src/lib/libcrypto/engine/eng_all.c
+++ b/src/lib/libcrypto/engine/eng_all.c
@@ -60,10 +60,6 @@
 #include <openssl/engine.h>
 #include "eng_int.h"
 
-#ifdef __OpenBSD__
-static int openbsd_default_loaded = 0;
-#endif
-
 void ENGINE_load_builtin_engines(void)
         {
         /* There's no longer any need for an "openssl" ENGINE unless, one day,
@@ -96,23 +92,11 @@ void ENGINE_load_builtin_engines(void)
 #ifndef OPENSSL_NO_HW_SUREWARE
         ENGINE_load_sureware();
 #endif
+#ifndef OPENSSL_NO_HW_4758_CCA
+        ENGINE_load_4758cca();
+#endif
 #ifdef OPENSSL_OPENBSD_DEV_CRYPTO
         ENGINE_load_openbsd_dev_crypto();
 #endif
-#ifdef __OpenBSD__
-        ENGINE_load_cryptodev();
-#endif
 #endif
         }
-
-#ifdef __OpenBSD__
-void ENGINE_setup_openbsd(void) {
-        if (!openbsd_default_loaded) {
-                ENGINE_load_cryptodev();
-                ENGINE_register_all_complete();
-        }
-        openbsd_default_loaded=1;
-}
-#endif
-
-
diff --git a/src/lib/libcrypto/engine/eng_fat.c b/src/lib/libcrypto/engine/eng_fat.c
index af918b1499..d49aa7ed40 100644
--- a/src/lib/libcrypto/engine/eng_fat.c
+++ b/src/lib/libcrypto/engine/eng_fat.c
@@ -141,8 +141,7 @@ int ENGINE_register_all_complete(void)
         {
         ENGINE *e;
 
-        for(e=ENGINE_get_first() ; e ; e=ENGINE_get_next(e)) {
+        for(e=ENGINE_get_first() ; e ; e=ENGINE_get_next(e))
                 ENGINE_register_complete(e);
-        }
         return 1;
         }
diff --git a/src/lib/libcrypto/engine/eng_init.c b/src/lib/libcrypto/engine/eng_init.c
index cc9396e863..98caa21e32 100644
--- a/src/lib/libcrypto/engine/eng_init.c
+++ b/src/lib/libcrypto/engine/eng_init.c
@@ -93,7 +93,7 @@ int engine_unlocked_finish(ENGINE *e, int unlock_for_handlers)
          * there's a chance that both threads will together take the count from
          * 2 to 0 without either calling finish(). */
         e->funct_ref--;
-        engine_ref_debug(e, 1, -1);
+        engine_ref_debug(e, 1, -1)
         if((e->funct_ref == 0) && e->finish)
                 {
                 if(unlock_for_handlers)
@@ -155,4 +155,3 @@ int ENGINE_finish(ENGINE *e)
                 }
         return to_return;
         }
-
diff --git a/src/lib/libcrypto/engine/eng_list.c b/src/lib/libcrypto/engine/eng_list.c
index ce48d2255a..0c220558e7 100644
--- a/src/lib/libcrypto/engine/eng_list.c
+++ b/src/lib/libcrypto/engine/eng_list.c
@@ -348,7 +348,7 @@ ENGINE *ENGINE_by_id(const char *id)
                 }
         CRYPTO_r_lock(CRYPTO_LOCK_ENGINE);
         iterator = engine_list_head;
-        while(iterator && (strcmp(id, iterator->id) != 0)) 
+        while(iterator && (strcmp(id, iterator->id) != 0))
                 iterator = iterator->next;
         if(iterator)
                 {
diff --git a/src/lib/libcrypto/engine/engine.h b/src/lib/libcrypto/engine/engine.h
index 2983f47034..cf06618286 100644
--- a/src/lib/libcrypto/engine/engine.h
+++ b/src/lib/libcrypto/engine/engine.h
@@ -3,7 +3,7 @@
  * project 2000.
  */
 /* ====================================================================
- * Copyright (c) 1999 The OpenSSL Project.  All rights reserved.
+ * Copyright (c) 1999-2001 The OpenSSL Project.  All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -59,36 +59,171 @@
 #ifndef HEADER_ENGINE_H
 #define HEADER_ENGINE_H
 
+#include <openssl/ossl_typ.h>
 #include <openssl/bn.h>
+#ifndef OPENSSL_NO_RSA
 #include <openssl/rsa.h>
+#endif
+#ifndef OPENSSL_NO_DSA
 #include <openssl/dsa.h>
+#endif
+#ifndef OPENSSL_NO_DH
 #include <openssl/dh.h>
+#endif
 #include <openssl/rand.h>
-#include <openssl/evp.h>
+#include <openssl/ui.h>
 #include <openssl/symhacks.h>
+#include <openssl/err.h>
 
 #ifdef  __cplusplus
 extern "C" {
 #endif
 
+/* Fixups for missing algorithms */
+#ifdef OPENSSL_NO_RSA
+typedef void RSA_METHOD;
+#endif
+#ifdef OPENSSL_NO_DSA
+typedef void DSA_METHOD;
+#endif
+#ifdef OPENSSL_NO_DH
+typedef void DH_METHOD;
+#endif
+
 /* These flags are used to control combinations of algorithm (methods)
  * by bitwise "OR"ing. */
 #define ENGINE_METHOD_RSA               (unsigned int)0x0001
 #define ENGINE_METHOD_DSA               (unsigned int)0x0002
 #define ENGINE_METHOD_DH                (unsigned int)0x0004
 #define ENGINE_METHOD_RAND              (unsigned int)0x0008
-#define ENGINE_METHOD_BN_MOD_EXP        (unsigned int)0x0010
-#define ENGINE_METHOD_BN_MOD_EXP_CRT    (unsigned int)0x0020
+#define ENGINE_METHOD_CIPHERS           (unsigned int)0x0040
+#define ENGINE_METHOD_DIGESTS           (unsigned int)0x0080
 /* Obvious all-or-nothing cases. */
 #define ENGINE_METHOD_ALL               (unsigned int)0xFFFF
 #define ENGINE_METHOD_NONE              (unsigned int)0x0000
 
+/* This(ese) flag(s) controls behaviour of the ENGINE_TABLE mechanism used
+ * internally to control registration of ENGINE implementations, and can be set
+ * by ENGINE_set_table_flags(). The "NOINIT" flag prevents attempts to
+ * initialise registered ENGINEs if they are not already initialised. */
+#define ENGINE_TABLE_FLAG_NOINIT        (unsigned int)0x0001
+
+/* ENGINE flags that can be set by ENGINE_set_flags(). */
+/* #define ENGINE_FLAGS_MALLOCED        0x0001 */ /* Not used */
+
+/* This flag is for ENGINEs that wish to handle the various 'CMD'-related
+ * control commands on their own. Without this flag, ENGINE_ctrl() handles these
+ * control commands on behalf of the ENGINE using their "cmd_defns" data. */
+#define ENGINE_FLAGS_MANUAL_CMD_CTRL    (int)0x0002
+
+/* This flag is for ENGINEs who return new duplicate structures when found via
+ * "ENGINE_by_id()". When an ENGINE must store state (eg. if ENGINE_ctrl()
+ * commands are called in sequence as part of some stateful process like
+ * key-generation setup and execution), it can set this flag - then each attempt
+ * to obtain the ENGINE will result in it being copied into a new structure.
+ * Normally, ENGINEs don't declare this flag so ENGINE_by_id() just increments
+ * the existing ENGINE's structural reference count. */
+#define ENGINE_FLAGS_BY_ID_COPY         (int)0x0004
+
+/* ENGINEs can support their own command types, and these flags are used in
+ * ENGINE_CTRL_GET_CMD_FLAGS to indicate to the caller what kind of input each
+ * command expects. Currently only numeric and string input is supported. If a
+ * control command supports none of the _NUMERIC, _STRING, or _NO_INPUT options,
+ * then it is regarded as an "internal" control command - and not for use in
+ * config setting situations. As such, they're not available to the
+ * ENGINE_ctrl_cmd_string() function, only raw ENGINE_ctrl() access. Changes to
+ * this list of 'command types' should be reflected carefully in
+ * ENGINE_cmd_is_executable() and ENGINE_ctrl_cmd_string(). */
+
+/* accepts a 'long' input value (3rd parameter to ENGINE_ctrl) */
+#define ENGINE_CMD_FLAG_NUMERIC         (unsigned int)0x0001
+/* accepts string input (cast from 'void*' to 'const char *', 4th parameter to
+ * ENGINE_ctrl) */
+#define ENGINE_CMD_FLAG_STRING          (unsigned int)0x0002
+/* Indicates that the control command takes *no* input. Ie. the control command
+ * is unparameterised. */
+#define ENGINE_CMD_FLAG_NO_INPUT        (unsigned int)0x0004
+/* Indicates that the control command is internal. This control command won't
+ * be shown in any output, and is only usable through the ENGINE_ctrl_cmd()
+ * function. */
+#define ENGINE_CMD_FLAG_INTERNAL        (unsigned int)0x0008
+
+/* NB: These 3 control commands are deprecated and should not be used. ENGINEs
+ * relying on these commands should compile conditional support for
+ * compatibility (eg. if these symbols are defined) but should also migrate the
+ * same functionality to their own ENGINE-specific control functions that can be
+ * "discovered" by calling applications. The fact these control commands
+ * wouldn't be "executable" (ie. usable by text-based config) doesn't change the
+ * fact that application code can find and use them without requiring per-ENGINE
+ * hacking. */
+
 /* These flags are used to tell the ctrl function what should be done.
  * All command numbers are shared between all engines, even if some don't
  * make sense to some engines.  In such a case, they do nothing but return
  * the error ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED. */
 #define ENGINE_CTRL_SET_LOGSTREAM               1
 #define ENGINE_CTRL_SET_PASSWORD_CALLBACK       2
+#define ENGINE_CTRL_HUP                         3 /* Close and reinitialise any
+                                                     handles/connections etc. */
+#define ENGINE_CTRL_SET_USER_INTERFACE          4 /* Alternative to callback */
+#define ENGINE_CTRL_SET_CALLBACK_DATA           5 /* User-specific data, used
+                                                     when calling the password
+                                                     callback and the user
+                                                     interface */
+
+/* These control commands allow an application to deal with an arbitrary engine
+ * in a dynamic way. Warn: Negative return values indicate errors FOR THESE
+ * COMMANDS because zero is used to indicate 'end-of-list'. Other commands,
+ * including ENGINE-specific command types, return zero for an error.
+ *
+ * An ENGINE can choose to implement these ctrl functions, and can internally
+ * manage things however it chooses - it does so by setting the
+ * ENGINE_FLAGS_MANUAL_CMD_CTRL flag (using ENGINE_set_flags()). Otherwise the
+ * ENGINE_ctrl() code handles this on the ENGINE's behalf using the cmd_defns
+ * data (set using ENGINE_set_cmd_defns()). This means an ENGINE's ctrl()
+ * handler need only implement its own commands - the above "meta" commands will
+ * be taken care of. */
+
+/* Returns non-zero if the supplied ENGINE has a ctrl() handler. If "not", then
+ * all the remaining control commands will return failure, so it is worth
+ * checking this first if the caller is trying to "discover" the engine's
+ * capabilities and doesn't want errors generated unnecessarily. */
+#define ENGINE_CTRL_HAS_CTRL_FUNCTION           10
+/* Returns a positive command number for the first command supported by the
+ * engine. Returns zero if no ctrl commands are supported. */
+#define ENGINE_CTRL_GET_FIRST_CMD_TYPE          11
+/* The 'long' argument specifies a command implemented by the engine, and the
+ * return value is the next command supported, or zero if there are no more. */
+#define ENGINE_CTRL_GET_NEXT_CMD_TYPE           12
+/* The 'void*' argument is a command name (cast from 'const char *'), and the
+ * return value is the command that corresponds to it. */
+#define ENGINE_CTRL_GET_CMD_FROM_NAME           13
+/* The next two allow a command to be converted into its corresponding string
+ * form. In each case, the 'long' argument supplies the command. In the NAME_LEN
+ * case, the return value is the length of the command name (not counting a
+ * trailing EOL). In the NAME case, the 'void*' argument must be a string buffer
+ * large enough, and it will be populated with the name of the command (WITH a
+ * trailing EOL). */
+#define ENGINE_CTRL_GET_NAME_LEN_FROM_CMD       14
+#define ENGINE_CTRL_GET_NAME_FROM_CMD           15
+/* The next two are similar but give a "short description" of a command. */
+#define ENGINE_CTRL_GET_DESC_LEN_FROM_CMD       16
+#define ENGINE_CTRL_GET_DESC_FROM_CMD           17
+/* With this command, the return value is the OR'd combination of
+ * ENGINE_CMD_FLAG_*** values that indicate what kind of input a given
+ * engine-specific ctrl command expects. */
+#define ENGINE_CTRL_GET_CMD_FLAGS               18
+
+/* ENGINE implementations should start the numbering of their own control
+ * commands from this value. (ie. ENGINE_CMD_BASE, ENGINE_CMD_BASE + 1, etc). */
+#define ENGINE_CMD_BASE         200
+
+/* NB: These 2 nCipher "chil" control commands are deprecated, and their
+ * functionality is now available through ENGINE-specific control commands
+ * (exposed through the above-mentioned 'CMD'-handling). Code using these 2
+ * commands should be migrated to the more general command handling before these
+ * are removed. */
+
 /* Flags specific to the nCipher "chil" engine */
 #define ENGINE_CTRL_CHIL_SET_FORKCHECK          100
         /* Depending on the value of the (long)i argument, this sets or
@@ -99,45 +234,55 @@ extern "C" {
         /* This prevents the initialisation function from providing mutex
          * callbacks to the nCipher library. */
 
-/* As we're missing a BIGNUM_METHOD, we need a couple of locally
- * defined function types that engines can implement. */
-
-#ifndef HEADER_ENGINE_INT_H
-/* mod_exp operation, calculates; r = a ^ p mod m
- * NB: ctx can be NULL, but if supplied, the implementation may use
- * it if it wishes. */
-typedef int (*BN_MOD_EXP)(BIGNUM *r, BIGNUM *a, const BIGNUM *p,
-                const BIGNUM *m, BN_CTX *ctx);
-
-/* private key operation for RSA, provided seperately in case other
- * RSA implementations wish to use it. */
-typedef int (*BN_MOD_EXP_CRT)(BIGNUM *r, BIGNUM *a, const BIGNUM *p,
-                const BIGNUM *q, const BIGNUM *dmp1, const BIGNUM *dmq1,
-                const BIGNUM *iqmp, BN_CTX *ctx);
+/* If an ENGINE supports its own specific control commands and wishes the
+ * framework to handle the above 'ENGINE_CMD_***'-manipulation commands on its
+ * behalf, it should supply a null-terminated array of ENGINE_CMD_DEFN entries
+ * to ENGINE_set_cmd_defns(). It should also implement a ctrl() handler that
+ * supports the stated commands (ie. the "cmd_num" entries as described by the
+ * array). NB: The array must be ordered in increasing order of cmd_num.
+ * "null-terminated" means that the last ENGINE_CMD_DEFN element has cmd_num set
+ * to zero and/or cmd_name set to NULL. */
+typedef struct ENGINE_CMD_DEFN_st
+        {
+        unsigned int cmd_num; /* The command number */
+        const char *cmd_name; /* The command name itself */
+        const char *cmd_desc; /* A short description of the command */
+        unsigned int cmd_flags; /* The input the command expects */
+        } ENGINE_CMD_DEFN;
 
 /* Generic function pointer */
-typedef void (*ENGINE_GEN_FUNC_PTR)();
+typedef int (*ENGINE_GEN_FUNC_PTR)();
 /* Generic function pointer taking no arguments */
-typedef void (*ENGINE_GEN_INT_FUNC_PTR)(void);
+typedef int (*ENGINE_GEN_INT_FUNC_PTR)(ENGINE *);
 /* Specific control function pointer */
-typedef int (*ENGINE_CTRL_FUNC_PTR)(int cmd, long i, void *p, void (*f)());
-
-/* The list of "engine" types is a static array of (const ENGINE*)
- * pointers (not dynamic because static is fine for now and we otherwise
- * have to hook an appropriate load/unload function in to initialise and
- * cleanup). */
-typedef struct engine_st ENGINE;
-#endif
+typedef int (*ENGINE_CTRL_FUNC_PTR)(ENGINE *, int, long, void *, void (*f)());
+/* Generic load_key function pointer */
+typedef EVP_PKEY * (*ENGINE_LOAD_KEY_PTR)(ENGINE *, const char *,
+        UI_METHOD *ui_method, void *callback_data);
+/* These callback types are for an ENGINE's handler for cipher and digest logic.
+ * These handlers have these prototypes;
+ *   int foo(ENGINE *e, const EVP_CIPHER **cipher, const int **nids, int nid);
+ *   int foo(ENGINE *e, const EVP_MD **digest, const int **nids, int nid);
+ * Looking at how to implement these handlers in the case of cipher support, if
+ * the framework wants the EVP_CIPHER for 'nid', it will call;
+ *   foo(e, &p_evp_cipher, NULL, nid);    (return zero for failure)
+ * If the framework wants a list of supported 'nid's, it will call;
+ *   foo(e, NULL, &p_nids, 0); (returns number of 'nids' or -1 for error)
+ */
+/* Returns to a pointer to the array of supported cipher 'nid's. If the second
+ * parameter is non-NULL it is set to the size of the returned array. */
+typedef int (*ENGINE_CIPHERS_PTR)(ENGINE *, const EVP_CIPHER **, const int **, int);
+typedef int (*ENGINE_DIGESTS_PTR)(ENGINE *, const EVP_MD **, const int **, int);
 
-/* STRUCTURE functions ... all of these functions deal with pointers to
- * ENGINE structures where the pointers have a "structural reference".
- * This means that their reference is to allow access to the structure
- * but it does not imply that the structure is functional. To simply
- * increment or decrement the structural reference count, use ENGINE_new
- * and ENGINE_free. NB: This is not required when iterating using
- * ENGINE_get_next as it will automatically decrement the structural
- * reference count of the "current" ENGINE and increment the structural
- * reference count of the ENGINE it returns (unless it is NULL). */
+/* STRUCTURE functions ... all of these functions deal with pointers to ENGINE
+ * structures where the pointers have a "structural reference". This means that
+ * their reference is to allowed access to the structure but it does not imply
+ * that the structure is functional. To simply increment or decrement the
+ * structural reference count, use ENGINE_by_id and ENGINE_free. NB: This is not
+ * required when iterating using ENGINE_get_next as it will automatically
+ * decrement the structural reference count of the "current" ENGINE and
+ * increment the structural reference count of the ENGINE it returns (unless it
+ * is NULL). */
 
 /* Get the first/last "ENGINE" type available. */
 ENGINE *ENGINE_get_first(void);
@@ -151,67 +296,167 @@ int ENGINE_add(ENGINE *e);
 int ENGINE_remove(ENGINE *e);
 /* Retrieve an engine from the list by its unique "id" value. */
 ENGINE *ENGINE_by_id(const char *id);
+/* Add all the built-in engines. */
+void ENGINE_load_openssl(void);
+void ENGINE_load_dynamic(void);
+void ENGINE_load_cswift(void);
+void ENGINE_load_chil(void);
+void ENGINE_load_atalla(void);
+void ENGINE_load_nuron(void);
+void ENGINE_load_ubsec(void);
+void ENGINE_load_aep(void);
+void ENGINE_load_sureware(void);
+void ENGINE_load_4758cca(void);
+void ENGINE_load_openbsd_dev_crypto(void);
+void ENGINE_load_builtin_engines(void);
 
-/* These functions are useful for manufacturing new ENGINE
- * structures. They don't address reference counting at all -
- * one uses them to populate an ENGINE structure with personalised
- * implementations of things prior to using it directly or adding
- * it to the builtin ENGINE list in OpenSSL. These are also here
- * so that the ENGINE structure doesn't have to be exposed and
- * break binary compatibility!
- *
- * NB: I'm changing ENGINE_new to force the ENGINE structure to
- * be allocated from within OpenSSL. See the comment for
- * ENGINE_get_struct_size().
- */
-#if 0
-ENGINE *ENGINE_new(ENGINE *e);
-#else
+/* Get and set global flags (ENGINE_TABLE_FLAG_***) for the implementation
+ * "registry" handling. */
+unsigned int ENGINE_get_table_flags(void);
+void ENGINE_set_table_flags(unsigned int flags);
+
+/* Manage registration of ENGINEs per "table". For each type, there are 3
+ * functions;
+ *   ENGINE_register_***(e) - registers the implementation from 'e' (if it has one)
+ *   ENGINE_unregister_***(e) - unregister the implementation from 'e'
+ *   ENGINE_register_all_***() - call ENGINE_register_***() for each 'e' in the list
+ * Cleanup is automatically registered from each table when required, so
+ * ENGINE_cleanup() will reverse any "register" operations. */
+
+int ENGINE_register_RSA(ENGINE *e);
+void ENGINE_unregister_RSA(ENGINE *e);
+void ENGINE_register_all_RSA(void);
+
+int ENGINE_register_DSA(ENGINE *e);
+void ENGINE_unregister_DSA(ENGINE *e);
+void ENGINE_register_all_DSA(void);
+
+int ENGINE_register_DH(ENGINE *e);
+void ENGINE_unregister_DH(ENGINE *e);
+void ENGINE_register_all_DH(void);
+
+int ENGINE_register_RAND(ENGINE *e);
+void ENGINE_unregister_RAND(ENGINE *e);
+void ENGINE_register_all_RAND(void);
+
+int ENGINE_register_ciphers(ENGINE *e);
+void ENGINE_unregister_ciphers(ENGINE *e);
+void ENGINE_register_all_ciphers(void);
+
+int ENGINE_register_digests(ENGINE *e);
+void ENGINE_unregister_digests(ENGINE *e);
+void ENGINE_register_all_digests(void);
+
+/* These functions register all support from the above categories. Note, use of
+ * these functions can result in static linkage of code your application may not
+ * need. If you only need a subset of functionality, consider using more
+ * selective initialisation. */
+int ENGINE_register_complete(ENGINE *e);
+int ENGINE_register_all_complete(void);
+
+/* Send parametrised control commands to the engine. The possibilities to send
+ * down an integer, a pointer to data or a function pointer are provided. Any of
+ * the parameters may or may not be NULL, depending on the command number. In
+ * actuality, this function only requires a structural (rather than functional)
+ * reference to an engine, but many control commands may require the engine be
+ * functional. The caller should be aware of trying commands that require an
+ * operational ENGINE, and only use functional references in such situations. */
+int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)());
+
+/* This function tests if an ENGINE-specific command is usable as a "setting".
+ * Eg. in an application's config file that gets processed through
+ * ENGINE_ctrl_cmd_string(). If this returns zero, it is not available to
+ * ENGINE_ctrl_cmd_string(), only ENGINE_ctrl(). */
+int ENGINE_cmd_is_executable(ENGINE *e, int cmd);
+
+/* This function works like ENGINE_ctrl() with the exception of taking a
+ * command name instead of a command number, and can handle optional commands.
+ * See the comment on ENGINE_ctrl_cmd_string() for an explanation on how to
+ * use the cmd_name and cmd_optional. */
+int ENGINE_ctrl_cmd(ENGINE *e, const char *cmd_name,
+        long i, void *p, void (*f)(), int cmd_optional);
+
+/* This function passes a command-name and argument to an ENGINE. The cmd_name
+ * is converted to a command number and the control command is called using
+ * 'arg' as an argument (unless the ENGINE doesn't support such a command, in
+ * which case no control command is called). The command is checked for input
+ * flags, and if necessary the argument will be converted to a numeric value. If
+ * cmd_optional is non-zero, then if the ENGINE doesn't support the given
+ * cmd_name the return value will be success anyway. This function is intended
+ * for applications to use so that users (or config files) can supply
+ * engine-specific config data to the ENGINE at run-time to control behaviour of
+ * specific engines. As such, it shouldn't be used for calling ENGINE_ctrl()
+ * functions that return data, deal with binary data, or that are otherwise
+ * supposed to be used directly through ENGINE_ctrl() in application code. Any
+ * "return" data from an ENGINE_ctrl() operation in this function will be lost -
+ * the return value is interpreted as failure if the return value is zero,
+ * success otherwise, and this function returns a boolean value as a result. In
+ * other words, vendors of 'ENGINE'-enabled devices should write ENGINE
+ * implementations with parameterisations that work in this scheme, so that
+ * compliant ENGINE-based applications can work consistently with the same
+ * configuration for the same ENGINE-enabled devices, across applications. */
+int ENGINE_ctrl_cmd_string(ENGINE *e, const char *cmd_name, const char *arg,
+                                int cmd_optional);
+
+/* These functions are useful for manufacturing new ENGINE structures. They
+ * don't address reference counting at all - one uses them to populate an ENGINE
+ * structure with personalised implementations of things prior to using it
+ * directly or adding it to the builtin ENGINE list in OpenSSL. These are also
+ * here so that the ENGINE structure doesn't have to be exposed and break binary
+ * compatibility! */
 ENGINE *ENGINE_new(void);
-#endif
 int ENGINE_free(ENGINE *e);
 int ENGINE_set_id(ENGINE *e, const char *id);
 int ENGINE_set_name(ENGINE *e, const char *name);
-int ENGINE_set_RSA(ENGINE *e, RSA_METHOD *rsa_meth);
-int ENGINE_set_DSA(ENGINE *e, DSA_METHOD *dsa_meth);
-int ENGINE_set_DH(ENGINE *e, DH_METHOD *dh_meth);
-int ENGINE_set_RAND(ENGINE *e, RAND_METHOD *rand_meth);
-int ENGINE_set_BN_mod_exp(ENGINE *e, BN_MOD_EXP bn_mod_exp);
-int ENGINE_set_BN_mod_exp_crt(ENGINE *e, BN_MOD_EXP_CRT bn_mod_exp_crt);
+int ENGINE_set_RSA(ENGINE *e, const RSA_METHOD *rsa_meth);
+int ENGINE_set_DSA(ENGINE *e, const DSA_METHOD *dsa_meth);
+int ENGINE_set_DH(ENGINE *e, const DH_METHOD *dh_meth);
+int ENGINE_set_RAND(ENGINE *e, const RAND_METHOD *rand_meth);
+int ENGINE_set_destroy_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR destroy_f);
 int ENGINE_set_init_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR init_f);
 int ENGINE_set_finish_function(ENGINE *e, ENGINE_GEN_INT_FUNC_PTR finish_f);
 int ENGINE_set_ctrl_function(ENGINE *e, ENGINE_CTRL_FUNC_PTR ctrl_f);
+int ENGINE_set_load_privkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpriv_f);
+int ENGINE_set_load_pubkey_function(ENGINE *e, ENGINE_LOAD_KEY_PTR loadpub_f);
+int ENGINE_set_ciphers(ENGINE *e, ENGINE_CIPHERS_PTR f);
+int ENGINE_set_digests(ENGINE *e, ENGINE_DIGESTS_PTR f);
+int ENGINE_set_flags(ENGINE *e, int flags);
+int ENGINE_set_cmd_defns(ENGINE *e, const ENGINE_CMD_DEFN *defns);
+/* These functions (and the "get" function lower down) allow control over any
+ * per-structure ENGINE data. */
+int ENGINE_get_ex_new_index(long argl, void *argp, CRYPTO_EX_new *new_func,
+                CRYPTO_EX_dup *dup_func, CRYPTO_EX_free *free_func);
+int ENGINE_set_ex_data(ENGINE *e, int idx, void *arg);
 
-/* These return values from within the ENGINE structure. These can
- * be useful with functional references as well as structural
- * references - it depends which you obtained. Using the result
- * for functional purposes if you only obtained a structural
- * reference may be problematic! */
-const char *ENGINE_get_id(ENGINE *e);
-const char *ENGINE_get_name(ENGINE *e);
-RSA_METHOD *ENGINE_get_RSA(ENGINE *e);
-DSA_METHOD *ENGINE_get_DSA(ENGINE *e);
-DH_METHOD *ENGINE_get_DH(ENGINE *e);
-RAND_METHOD *ENGINE_get_RAND(ENGINE *e);
-BN_MOD_EXP ENGINE_get_BN_mod_exp(ENGINE *e);
-BN_MOD_EXP_CRT ENGINE_get_BN_mod_exp_crt(ENGINE *e);
-ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(ENGINE *e);
-ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(ENGINE *e);
-ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(ENGINE *e);
-
-/* ENGINE_new is normally passed a NULL in the first parameter because
- * the calling code doesn't have access to the definition of the ENGINE
- * structure (for good reason). However, if the caller wishes to use
- * its own memory allocation or use a static array, the following call
- * should be used to check the amount of memory the ENGINE structure
- * will occupy. This will make the code more future-proof.
- *
- * NB: I'm "#if 0"-ing this out because it's better to force the use of
- * internally allocated memory. See similar change in ENGINE_new().
- */
-#if 0
-int ENGINE_get_struct_size(void);
-#endif
+/* This function cleans up anything that needs it. Eg. the ENGINE_add() function
+ * automatically ensures the list cleanup function is registered to be called
+ * from ENGINE_cleanup(). Similarly, all ENGINE_register_*** functions ensure
+ * ENGINE_cleanup() will clean up after them. */
+void ENGINE_cleanup(void);
+
+/* These return values from within the ENGINE structure. These can be useful
+ * with functional references as well as structural references - it depends
+ * which you obtained. Using the result for functional purposes if you only
+ * obtained a structural reference may be problematic! */
+const char *ENGINE_get_id(const ENGINE *e);
+const char *ENGINE_get_name(const ENGINE *e);
+const RSA_METHOD *ENGINE_get_RSA(const ENGINE *e);
+const DSA_METHOD *ENGINE_get_DSA(const ENGINE *e);
+const DH_METHOD *ENGINE_get_DH(const ENGINE *e);
+const RAND_METHOD *ENGINE_get_RAND(const ENGINE *e);
+ENGINE_GEN_INT_FUNC_PTR ENGINE_get_destroy_function(const ENGINE *e);
+ENGINE_GEN_INT_FUNC_PTR ENGINE_get_init_function(const ENGINE *e);
+ENGINE_GEN_INT_FUNC_PTR ENGINE_get_finish_function(const ENGINE *e);
+ENGINE_CTRL_FUNC_PTR ENGINE_get_ctrl_function(const ENGINE *e);
+ENGINE_LOAD_KEY_PTR ENGINE_get_load_privkey_function(const ENGINE *e);
+ENGINE_LOAD_KEY_PTR ENGINE_get_load_pubkey_function(const ENGINE *e);
+ENGINE_CIPHERS_PTR ENGINE_get_ciphers(const ENGINE *e);
+ENGINE_DIGESTS_PTR ENGINE_get_digests(const ENGINE *e);
+const EVP_CIPHER *ENGINE_get_cipher(ENGINE *e, int nid);
+const EVP_MD *ENGINE_get_digest(ENGINE *e, int nid);
+const ENGINE_CMD_DEFN *ENGINE_get_cmd_defns(const ENGINE *e);
+int ENGINE_get_flags(const ENGINE *e);
+void *ENGINE_get_ex_data(const ENGINE *e, int idx);
 
 /* FUNCTIONAL functions. These functions deal with ENGINE structures
  * that have (or will) be initialised for use. Broadly speaking, the
@@ -233,20 +478,14 @@ int ENGINE_init(ENGINE *e);
  * a corresponding call to ENGINE_free as it also releases a structural
  * reference. */
 int ENGINE_finish(ENGINE *e);
-/* Send control parametrised commands to the engine.  The possibilities
- * to send down an integer, a pointer to data or a function pointer are
- * provided.  Any of the parameters may or may not be NULL, depending
- * on the command number */
-/* WARNING: This is currently experimental and may change radically! */
-int ENGINE_ctrl(ENGINE *e, int cmd, long i, void *p, void (*f)());
 
 /* The following functions handle keys that are stored in some secondary
  * location, handled by the engine.  The storage may be on a card or
  * whatever. */
 EVP_PKEY *ENGINE_load_private_key(ENGINE *e, const char *key_id,
-        const char *passphrase);
+        UI_METHOD *ui_method, void *callback_data);
 EVP_PKEY *ENGINE_load_public_key(ENGINE *e, const char *key_id,
-        const char *passphrase);
+        UI_METHOD *ui_method, void *callback_data);
 
 /* This returns a pointer for the current ENGINE structure that
  * is (by default) performing any RSA operations. The value returned
@@ -257,117 +496,192 @@ ENGINE *ENGINE_get_default_RSA(void);
 ENGINE *ENGINE_get_default_DSA(void);
 ENGINE *ENGINE_get_default_DH(void);
 ENGINE *ENGINE_get_default_RAND(void);
-ENGINE *ENGINE_get_default_BN_mod_exp(void);
-ENGINE *ENGINE_get_default_BN_mod_exp_crt(void);
+/* These functions can be used to get a functional reference to perform
+ * ciphering or digesting corresponding to "nid". */
+ENGINE *ENGINE_get_cipher_engine(int nid);
+ENGINE *ENGINE_get_digest_engine(int nid);
 
 /* This sets a new default ENGINE structure for performing RSA
  * operations. If the result is non-zero (success) then the ENGINE
  * structure will have had its reference count up'd so the caller
  * should still free their own reference 'e'. */
 int ENGINE_set_default_RSA(ENGINE *e);
+int ENGINE_set_default_string(ENGINE *e, const char *list);
 /* Same for the other "methods" */
 int ENGINE_set_default_DSA(ENGINE *e);
 int ENGINE_set_default_DH(ENGINE *e);
 int ENGINE_set_default_RAND(ENGINE *e);
-int ENGINE_set_default_BN_mod_exp(ENGINE *e);
-int ENGINE_set_default_BN_mod_exp_crt(ENGINE *e);
+int ENGINE_set_default_ciphers(ENGINE *e);
+int ENGINE_set_default_digests(ENGINE *e);
 
 /* The combination "set" - the flags are bitwise "OR"d from the
- * ENGINE_METHOD_*** defines above. */
+ * ENGINE_METHOD_*** defines above. As with the "ENGINE_register_complete()"
+ * function, this function can result in unnecessary static linkage. If your
+ * application requires only specific functionality, consider using more
+ * selective functions. */
 int ENGINE_set_default(ENGINE *e, unsigned int flags);
 
-/* Obligatory error function. */
-void ERR_load_ENGINE_strings(void);
+void ENGINE_add_conf_module(void);
 
-/*
- * Error codes for all engine functions. NB: We use "generic"
- * function names instead of per-implementation ones because this
- * levels the playing field for externally implemented bootstrapped
- * support code. As the filename and line number is included, it's
- * more important to indicate the type of function, so that
- * bootstrapped code (that can't easily add its own errors in) can
- * use the same error codes too.
- */
+/* Deprecated functions ... */
+/* int ENGINE_clear_defaults(void); */
+
+/**************************/
+/* DYNAMIC ENGINE SUPPORT */
+/**************************/
+
+/* Binary/behaviour compatibility levels */
+#define OSSL_DYNAMIC_VERSION            (unsigned long)0x00010100
+/* Binary versions older than this are too old for us (whether we're a loader or
+ * a loadee) */
+#define OSSL_DYNAMIC_OLDEST             (unsigned long)0x00010100
+
+/* When compiling an ENGINE entirely as an external shared library, loadable by
+ * the "dynamic" ENGINE, these types are needed. The 'dynamic_fns' structure
+ * type provides the calling application's (or library's) error functionality
+ * and memory management function pointers to the loaded library. These should
+ * be used/set in the loaded library code so that the loading application's
+ * 'state' will be used/changed in all operations. */
+typedef void *(*dyn_MEM_malloc_cb)(size_t);
+typedef void *(*dyn_MEM_realloc_cb)(void *, size_t);
+typedef void (*dyn_MEM_free_cb)(void *);
+typedef struct st_dynamic_MEM_fns {
+        dyn_MEM_malloc_cb                       malloc_cb;
+        dyn_MEM_realloc_cb                      realloc_cb;
+        dyn_MEM_free_cb                         free_cb;
+        } dynamic_MEM_fns;
+/* FIXME: Perhaps the memory and locking code (crypto.h) should declare and use
+ * these types so we (and any other dependant code) can simplify a bit?? */
+typedef void (*dyn_lock_locking_cb)(int,int,const char *,int);
+typedef int (*dyn_lock_add_lock_cb)(int*,int,int,const char *,int);
+typedef struct CRYPTO_dynlock_value *(*dyn_dynlock_create_cb)(
+                                                const char *,int);
+typedef void (*dyn_dynlock_lock_cb)(int,struct CRYPTO_dynlock_value *,
+                                                const char *,int);
+typedef void (*dyn_dynlock_destroy_cb)(struct CRYPTO_dynlock_value *,
+                                                const char *,int);
+typedef struct st_dynamic_LOCK_fns {
+        dyn_lock_locking_cb                     lock_locking_cb;
+        dyn_lock_add_lock_cb                    lock_add_lock_cb;
+        dyn_dynlock_create_cb                   dynlock_create_cb;
+        dyn_dynlock_lock_cb                     dynlock_lock_cb;
+        dyn_dynlock_destroy_cb                  dynlock_destroy_cb;
+        } dynamic_LOCK_fns;
+/* The top-level structure */
+typedef struct st_dynamic_fns {
+        const ERR_FNS                           *err_fns;
+        const CRYPTO_EX_DATA_IMPL               *ex_data_fns;
+        dynamic_MEM_fns                         mem_fns;
+        dynamic_LOCK_fns                        lock_fns;
+        } dynamic_fns;
+
+/* The version checking function should be of this prototype. NB: The
+ * ossl_version value passed in is the OSSL_DYNAMIC_VERSION of the loading code.
+ * If this function returns zero, it indicates a (potential) version
+ * incompatibility and the loaded library doesn't believe it can proceed.
+ * Otherwise, the returned value is the (latest) version supported by the
+ * loading library. The loader may still decide that the loaded code's version
+ * is unsatisfactory and could veto the load. The function is expected to
+ * be implemented with the symbol name "v_check", and a default implementation
+ * can be fully instantiated with IMPLEMENT_DYNAMIC_CHECK_FN(). */
+typedef unsigned long (*dynamic_v_check_fn)(unsigned long ossl_version);
+#define IMPLEMENT_DYNAMIC_CHECK_FN() \
+        unsigned long v_check(unsigned long v) { \
+                if(v >= OSSL_DYNAMIC_OLDEST) return OSSL_DYNAMIC_VERSION; \
+                return 0; }
+
+/* This function is passed the ENGINE structure to initialise with its own
+ * function and command settings. It should not adjust the structural or
+ * functional reference counts. If this function returns zero, (a) the load will
+ * be aborted, (b) the previous ENGINE state will be memcpy'd back onto the
+ * structure, and (c) the shared library will be unloaded. So implementations
+ * should do their own internal cleanup in failure circumstances otherwise they
+ * could leak. The 'id' parameter, if non-NULL, represents the ENGINE id that
+ * the loader is looking for. If this is NULL, the shared library can choose to
+ * return failure or to initialise a 'default' ENGINE. If non-NULL, the shared
+ * library must initialise only an ENGINE matching the passed 'id'. The function
+ * is expected to be implemented with the symbol name "bind_engine". A standard
+ * implementation can be instantiated with IMPLEMENT_DYNAMIC_BIND_FN(fn) where
+ * the parameter 'fn' is a callback function that populates the ENGINE structure
+ * and returns an int value (zero for failure). 'fn' should have prototype;
+ *    [static] int fn(ENGINE *e, const char *id); */
+typedef int (*dynamic_bind_engine)(ENGINE *e, const char *id,
+                                const dynamic_fns *fns);
+#define IMPLEMENT_DYNAMIC_BIND_FN(fn) \
+        int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \
+                if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \
+                        fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \
+                        return 0; \
+                CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \
+                CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \
+                CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb); \
+                CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \
+                CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb); \
+                if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \
+                        return 0; \
+                if(!ERR_set_implementation(fns->err_fns)) return 0; \
+                if(!fn(e,id)) return 0; \
+                return 1; }
 
 /* BEGIN ERROR CODES */
 /* The following lines are auto generated by the script mkerr.pl. Any changes
  * made after this point may be overwritten when the script is next run.
  */
+void ERR_load_ENGINE_strings(void);
 
 /* Error codes for the ENGINE functions. */
 
 /* Function codes. */
-#define ENGINE_F_ATALLA_FINISH                           135
-#define ENGINE_F_ATALLA_INIT                             136
-#define ENGINE_F_ATALLA_MOD_EXP                          137
-#define ENGINE_F_ATALLA_RSA_MOD_EXP                      138
-#define ENGINE_F_CSWIFT_DSA_SIGN                         133
-#define ENGINE_F_CSWIFT_DSA_VERIFY                       134
-#define ENGINE_F_CSWIFT_FINISH                           100
-#define ENGINE_F_CSWIFT_INIT                             101
-#define ENGINE_F_CSWIFT_MOD_EXP                          102
-#define ENGINE_F_CSWIFT_MOD_EXP_CRT                      103
-#define ENGINE_F_CSWIFT_RSA_MOD_EXP                      104
+#define ENGINE_F_DYNAMIC_CTRL                            180
+#define ENGINE_F_DYNAMIC_GET_DATA_CTX                    181
+#define ENGINE_F_DYNAMIC_LOAD                            182
 #define ENGINE_F_ENGINE_ADD                              105
 #define ENGINE_F_ENGINE_BY_ID                            106
+#define ENGINE_F_ENGINE_CMD_IS_EXECUTABLE                170
 #define ENGINE_F_ENGINE_CTRL                             142
+#define ENGINE_F_ENGINE_CTRL_CMD                         178
+#define ENGINE_F_ENGINE_CTRL_CMD_STRING                  171
 #define ENGINE_F_ENGINE_FINISH                           107
 #define ENGINE_F_ENGINE_FREE                             108
-#define ENGINE_F_ENGINE_GET_BN_MOD_EXP                   109
-#define ENGINE_F_ENGINE_GET_BN_MOD_EXP_CRT               110
-#define ENGINE_F_ENGINE_GET_CTRL_FUNCTION                144
-#define ENGINE_F_ENGINE_GET_DH                           111
-#define ENGINE_F_ENGINE_GET_DSA                          112
-#define ENGINE_F_ENGINE_GET_FINISH_FUNCTION              145
-#define ENGINE_F_ENGINE_GET_ID                           113
-#define ENGINE_F_ENGINE_GET_INIT_FUNCTION                146
-#define ENGINE_F_ENGINE_GET_NAME                         114
+#define ENGINE_F_ENGINE_GET_CIPHER                       185
+#define ENGINE_F_ENGINE_GET_DEFAULT_TYPE                 177
+#define ENGINE_F_ENGINE_GET_DIGEST                       186
 #define ENGINE_F_ENGINE_GET_NEXT                         115
 #define ENGINE_F_ENGINE_GET_PREV                         116
-#define ENGINE_F_ENGINE_GET_RAND                         117
-#define ENGINE_F_ENGINE_GET_RSA                          118
 #define ENGINE_F_ENGINE_INIT                             119
 #define ENGINE_F_ENGINE_LIST_ADD                         120
 #define ENGINE_F_ENGINE_LIST_REMOVE                      121
 #define ENGINE_F_ENGINE_LOAD_PRIVATE_KEY                 150
 #define ENGINE_F_ENGINE_LOAD_PUBLIC_KEY                  151
+#define ENGINE_F_ENGINE_MODULE_INIT                      187
 #define ENGINE_F_ENGINE_NEW                              122
 #define ENGINE_F_ENGINE_REMOVE                           123
-#define ENGINE_F_ENGINE_SET_BN_MOD_EXP                   124
-#define ENGINE_F_ENGINE_SET_BN_MOD_EXP_CRT               125
-#define ENGINE_F_ENGINE_SET_CTRL_FUNCTION                147
+#define ENGINE_F_ENGINE_SET_DEFAULT_STRING               189
 #define ENGINE_F_ENGINE_SET_DEFAULT_TYPE                 126
-#define ENGINE_F_ENGINE_SET_DH                           127
-#define ENGINE_F_ENGINE_SET_DSA                          128
-#define ENGINE_F_ENGINE_SET_FINISH_FUNCTION              148
 #define ENGINE_F_ENGINE_SET_ID                           129
-#define ENGINE_F_ENGINE_SET_INIT_FUNCTION                149
 #define ENGINE_F_ENGINE_SET_NAME                         130
-#define ENGINE_F_ENGINE_SET_RAND                         131
-#define ENGINE_F_ENGINE_SET_RSA                          132
+#define ENGINE_F_ENGINE_TABLE_REGISTER                   184
 #define ENGINE_F_ENGINE_UNLOAD_KEY                       152
-#define ENGINE_F_HWCRHK_CTRL                             143
-#define ENGINE_F_HWCRHK_FINISH                           135
-#define ENGINE_F_HWCRHK_GET_PASS                         155
-#define ENGINE_F_HWCRHK_INIT                             136
-#define ENGINE_F_HWCRHK_LOAD_PRIVKEY                     153
-#define ENGINE_F_HWCRHK_LOAD_PUBKEY                      154
-#define ENGINE_F_HWCRHK_MOD_EXP                          137
-#define ENGINE_F_HWCRHK_MOD_EXP_CRT                      138
-#define ENGINE_F_HWCRHK_RAND_BYTES                       139
-#define ENGINE_F_HWCRHK_RSA_MOD_EXP                      140
+#define ENGINE_F_INT_CTRL_HELPER                         172
+#define ENGINE_F_INT_ENGINE_CONFIGURE                    188
 #define ENGINE_F_LOG_MESSAGE                             141
+#define ENGINE_F_SET_DATA_CTX                            183
 
 /* Reason codes. */
 #define ENGINE_R_ALREADY_LOADED                          100
-#define ENGINE_R_BIO_WAS_FREED                           121
-#define ENGINE_R_BN_CTX_FULL                             101
-#define ENGINE_R_BN_EXPAND_FAIL                          102
-#define ENGINE_R_CHIL_ERROR                              123
+#define ENGINE_R_ARGUMENT_IS_NOT_A_NUMBER                133
+#define ENGINE_R_CMD_NOT_EXECUTABLE                      134
+#define ENGINE_R_COMMAND_TAKES_INPUT                     135
+#define ENGINE_R_COMMAND_TAKES_NO_INPUT                  136
 #define ENGINE_R_CONFLICTING_ENGINE_ID                   103
 #define ENGINE_R_CTRL_COMMAND_NOT_IMPLEMENTED            119
+#define ENGINE_R_DH_NOT_IMPLEMENTED                      139
+#define ENGINE_R_DSA_NOT_IMPLEMENTED                     140
 #define ENGINE_R_DSO_FAILURE                             104
+#define ENGINE_R_DSO_NOT_FOUND                           132
+#define ENGINE_R_ENGINES_SECTION_ERROR                   148
 #define ENGINE_R_ENGINE_IS_NOT_IN_LIST                   105
+#define ENGINE_R_ENGINE_SECTION_ERROR                    149
 #define ENGINE_R_FAILED_LOADING_PRIVATE_KEY              128
 #define ENGINE_R_FAILED_LOADING_PUBLIC_KEY               129
 #define ENGINE_R_FINISH_FAILED                           106
@@ -375,24 +689,26 @@ void ERR_load_ENGINE_strings(void);
 #define ENGINE_R_ID_OR_NAME_MISSING                      108
 #define ENGINE_R_INIT_FAILED                             109
 #define ENGINE_R_INTERNAL_LIST_ERROR                     110
-#define ENGINE_R_MISSING_KEY_COMPONENTS                  111
+#define ENGINE_R_INVALID_ARGUMENT                        143
+#define ENGINE_R_INVALID_CMD_NAME                        137
+#define ENGINE_R_INVALID_CMD_NUMBER                      138
+#define ENGINE_R_INVALID_INIT_VALUE                      151
+#define ENGINE_R_INVALID_STRING                          150
 #define ENGINE_R_NOT_INITIALISED                         117
 #define ENGINE_R_NOT_LOADED                              112
-#define ENGINE_R_NO_CALLBACK                             127
 #define ENGINE_R_NO_CONTROL_FUNCTION                     120
-#define ENGINE_R_NO_KEY                                  124
+#define ENGINE_R_NO_INDEX                                144
 #define ENGINE_R_NO_LOAD_FUNCTION                        125
 #define ENGINE_R_NO_REFERENCE                            130
 #define ENGINE_R_NO_SUCH_ENGINE                          116
 #define ENGINE_R_NO_UNLOAD_FUNCTION                      126
 #define ENGINE_R_PROVIDE_PARAMETERS                      113
-#define ENGINE_R_REQUEST_FAILED                          114
-#define ENGINE_R_REQUEST_FALLBACK                        118
-#define ENGINE_R_SIZE_TOO_LARGE_OR_TOO_SMALL             122
-#define ENGINE_R_UNIT_FAILURE                            115
+#define ENGINE_R_RSA_NOT_IMPLEMENTED                     141
+#define ENGINE_R_UNIMPLEMENTED_CIPHER                    146
+#define ENGINE_R_UNIMPLEMENTED_DIGEST                    147
+#define ENGINE_R_VERSION_INCOMPATIBILITY                 145
 
 #ifdef  __cplusplus
 }
 #endif
 #endif
-