Lines Matching refs:ENGINE

7 the "ENGINE" code. So it serves a double purpose of being a "ENGINE internals
49 into ENGINE is storage - the OBJ_NAME-based storage used by EVP to register
53 solution is necessarily that ENGINE-provided ciphers simply are not registered,
55 especially necessary considering the fact ENGINE uses reference counts to allow
59 Another sticking point for integrating cipher support into ENGINE is linkage.
60 Already there is a problem with the way ENGINE supports RSA, DSA, etc whereby
61 they are available *because* they're part of a giant ENGINE called "openssl".
62 Ie. all implementations *have* to come from an ENGINE, but we get round that by
63 having a giant ENGINE with all the software support encapsulated. This creates
66 ENGINE code being linked in *and* because of that DSA, DH, and RAND also. If we
71 solution is to change the way ENGINE feeds existing "classes", ie. how the
72 hooking to ENGINE works from RSA, DSA, DH, RAND, as well as adding new hooking
76 work prior to ENGINE :-). Ie. RSA now has a "RSA_METHOD" pointer again - this
77 was previously replaced by an "ENGINE" pointer and all RSA code that required
78 the RSA_METHOD would call ENGINE_get_RSA() each time on its ENGINE handle to
79 temporarily get and use the ENGINE's RSA implementation. Apart from being more
81 us to conceivably operate with *no* ENGINE. As we'll see, this removes any need
82 for a fallback ENGINE that encapsulates default implementations - we can simply
84 implementation and have its ENGINE pointer set to NULL.
92 begin en/decryption, the hooking to ENGINE comes into play. What happens is that
93 cipher-specific ENGINE code is asked for an ENGINE pointer (a functional
94 reference) for any ENGINE that is registered to perform the algo/mode that the
96 ENGINE code will return NULL because no ENGINEs will have had any cipher
97 implementations *registered*. As such, a NULL ENGINE pointer is stored in the
100 except we'd have a redundant ENGINE pointer set to NULL and doing nothing.
102 Conversely, if an ENGINE *has* been registered to perform the algorithm/mode
104 to that ENGINE will be returned to the EVP_CIPHER_CTX during initialisation.
107 definition that is private to the ENGINE. Ie. the EVP_CIPHER provided by the
109 ENGINE - it will support the same algorithm/mode as the original but will be a
115 reference to the ENGINE that owns it, thus the use of the ENGINE's EVP_CIPHER is
118 The "cipher-specific ENGINE code" I mentioned is implemented in tb_cipher.c but
125 ENGINE code that is independent of class, and of course the ENGINE
127 class-specific ENGINE code for digests, RSA, etc nor will it bleed over into
140 a change is made to the pile, eg. perhaps an ENGINE was unloaded. The reason is
146 and will either return (and cache) a NULL ENGINE pointer or will return a
148 case it will also cache an extra functional reference to the ENGINE as a
169 application or EVP_CIPHER code releases its last reference to an ENGINE, the
172 new ENGINE changes, an abstract ENGINE can be loaded and initialised, but that
177 nothing to do with whether an ENGINE is *functional* or not (ie. you can even
178 register an ENGINE and its implementations without it being operational, you may
181 functions. These functions are internal-only and each part of ENGINE code that
185 initialised state. So if RSA code asks for an ENGINE and no ENGINE has
197 What else? The bignum callbacks and associated ENGINE functions have been
201 application code to automatically hook and use ENGINE supplied bignum functions
205 RSA, DSA, DH, and RAND functions that were fiddled during the original ENGINE
207 hooking of ENGINE is now automatic (and passive, it can internally use a NULL
208 ENGINE pointer to simply ignore ENGINE from then on).