[Date Prev][Date Next]
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, firstname.lastname@example.org wrote:
>Full_Name: blair christensen.
>OS: Solaris 8
>Submission from: (NULL) (184.108.40.206)
>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?