Re: Engine vs. Crypto Lib Question

[Verdon Walker]

Thanks for the feedback. I really appreciate it. We hope to be active, participating members of the OpenSSL community and this type of information really helps. It would appear that I had some misunderstandings about the Engine interface. Thanks for clearing them up. At this point, I think we will continue on the path we are on which, BTW, is well past the point of coding around the edges of OpenSSL (hard core as you would say :-). Since we are attempting primarily to hook our library in at the EVP layer, I do think much of what we find we need to do may be of use to your Engine development if that is the same level you are targetting for interfacing with SSL/TLS. (It should also simplify our task should we decide later to convert to the Engine interface.)   At this point, I will start taking a look at the development builds in an effort to push back any changes we are making (EVP implementation of digests, ciphers, etc.) in that context and hope that it can be of benefit to all of us.   Cheers.   Verdon Walker (801) 861-2633 [EMAIL PROTECTED] Novell Inc., the leading provider of Net Services Software www.novell.com >>> [EMAIL PROTECTED] 04/26/01 05:30PM >>> Hi there, If you're on the commit mail list you'll probably be aware why I haven't had a chance to answer your posts until now. :-) Thanks for the contributions w.r.t. standardising the use of EVP ... it's the kind of thing that needs doing and soon (see below #3) it will be even more important. Like Steve said, if you could work your patch into a recent snapshot of 0.9.7-dev, that would make life easier for us to review it and add it. On Thu, 26 Apr 2001, Verdon Walker wrote: > As I have mentioned before, we are currently producing an OpenSSL solution > that uses our own cryptography library for ALL cryptographic functionality > (instead of using libeay for those functions). We have elected to actually > replace the underlying crypto functions in libeay with calls to our own > library (at the EVP level wherever possible) instead of attempting to use the > ENGINE interface. We are doing this for various reasons and I wanted to run > them by you to see if our thinking is sound (or if we have missed something): Sure thing. The ENGINE stuff is moving quite swiftly - you'll probably see a number of fairly major improvements (and necessarily, changes) in the underlying code and the API before 0.9.7 approaches. On the one hand, this may provide you with something useful, on the other hand it may also scare you off until it settles down a bit. YMMV. > 1 - It appears that Engine is meant to provide support for alternate solutions > (primarily hardware), but will fall back to the libeay software solution if no > other engines exist. We must use our library for all cryptography. It is not > optional. Um, no. It is easy to code an ENGINE to fallback to another ENGINE in the event of ENGINE-specific errors, together with whatever retry logic is required. However, if an ENGINE doesn't support handling failed operations by falling back to something else, then any failed operation *stays* failed. If you simply want to ensure that the 'openssl' ENGINE isn't available or that its role is replaced - edit the 'engine_internal_check()' function in engine_list.c and replace the call to ENGINE_openssl() with the ENGINE you'd like to replace it with. > 2 - Engine does not support cryptography that is not also supported through > the standard software interface. Richard Levitte just started a thread on this > topic (Disabling algorithms) which is really what got me thinking about this > again. In any case, if we disable the current software solutions, it would > appear that we also disable any ability to provide the solutions through the > engine. See #1 to understand why this is not acceptable for us. Again, I don't think this is true (if I understood you correctly). See the answer to #1 to understand why. :-) > 3 - Engine does not currently support all cryptographic functionality. Most > notable would be symmetric ciphers, but we also need to use our library for > RAND and other functions that may not be supported either. RAND is supported through the ENGINE interface, and once again you could hard-code it in as the startup default if you wish. Symmetric cipher support is coming - I've already discussed with a couple of the others about how this can be done and some of the current changes are to better facilitate this. I envisage that EVP_CIPHER and EVP_MD support will be in the ENGINE code soon. The one thing it won't do due to far more fundamental difficulties is deal with opaque (hardware-managed) symmetric keys. That doesn't seem to be an issue for what you're doing, but it may be to someone else out there lurking and watching this. > 4 - Engine is still in early development and may not be as stable as the > standard code base. Testing welcomed. :-) It would be more accurate to say that the ENGINE code in CVS is undergoing a lot of new work. However, what exists in the 0.9.6a release is not "experimental" and it is in use in a number of secure commercial websites, FWIW. > 5 - We have not been able to find much documentation about how to use the > Engine interface. We have not been able to find many people writing documentation about how to use the ENGINE interface. In seriousness though, this is something on the list - but as there's already a lot of work on the code underway, it makes more sense to get the current priorities ticked off, and then look at documenting whatever remains.  However, the source code is reasonably well (OK, I admit it, *verbosely*) commented, and reading it at that level is probably a good idea for those needing to do anything hard-core anyway. (Ripping out the default software ENGINE and hard-wiring alternative libs in definitely counts IMHO). > This is probably not an exhaustive list, but is sufficient for making the > decision that Engine is not an option for providing the solution we want at > this time. >  > Am I incorrect in any of my assumptions or conclusions? Are there other > considerations I have missed that would make the Engine more palatable for > what we are doing? It may or may not be ... however if you're wanting to stay on the outside of the code then you may have to go without ENGINE for now or at least keep an eye on it so you could target your implementation to it when it's ready (ciphers and digests are obviously the main problem there). If you wish to start ferreting round *in* the ENGINE code, well then there's a bunch of stuff you could help with. <grin> Regards, Geoff ______________________________________________________________________ OpenSSL Project                                 http://www.openssl.org Development Mailing List                       [EMAIL PROTECTED] Automated List Manager                           [EMAIL PROTECTED]