[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Hardware Crypto Support w/ openssl-engine (ITS#1339)

I suggest you raise the issues for discussion on the developer's list.

At 08:50 AM 2001-09-19, blair+openldap@devclue.com wrote:
>Full_Name: blair christensen.
>Version: 2.0.14+
>OS: Solaris 8
>URL: ftp://ftp.openldap.org/incoming/
>Submission from: (NULL) (
>We are currently running OpenLDAP on several Solaris/Sparc servers, which of
>course do not provide a /dev/(u)random.  In the past we have used the ANDIrand
>package which provides a /dev/(u)random (quality of which I'm not entirely
>certain).  Now, however, we are purchasing hardware crypto cards to use on all
>of our machines. 
>The crypto cards do not provide a /dev/(u)random interface, but instead, using
>openssl-engine, you can tell openssl to use a specific hardware engine (in our
>case "cswift" but there are a few others as well) at run time (*not* compile
>time).  The default is to use the "openssl" engine, which basically tells
>openssl to behave normally, using a /dev/(u)random if present.
>I have currently made changes such that slapd (based upon changes in
>libraries/libldap/tls.c and a few other places), if given a TLSCryptEngine
>configuration option in slapd.conf, will use the hardware crypto and this seems
>to work.  However, I've realized that using my current methods, everything in
>$PREFIX/bin, $PREFIX/libexec, and $PREFIX/sbin would probably need to be
>explicitly modified to support the hardware crypto engine.  That is *ugly*.  
>Which brings me to my question/RFC: Do you have any suggestions/preferences for
>how I implement this (as I intend to submit all of my patches) such that is
>general enough to work across all binaries?  Should the crypto engine be set at
>compile time in libraries/libldap/tls.c (with a possible run time directive to
>override this) or should I take a different approach?  Perhaps an option in
>ldap.conf for the client tools to explicitly set the engine to use?
>blair christensen.