On 30/03/2010 12:46, Khyron wrote: > I remember reading somewhere that the *only* way to get an OpenSSL with > support for the Niagara on-chip crypto processors was to use the /usr/sfw > installed version (SUNWopenssl-* are the pkg names on my S10 Update 7 box). > > My question is why can I not compile OpenSSL from source to use those > accelerators? Have the changes that Sun has made not been fed back > upstream > to the OpenSSL project?
The only way to access the UltraSPARC T1/T2 hardware crypto from userland is via the private /dev/crypto interface. The only documented API to /dev/crypto is PKCS#11. > If so, have they been included? If they > haven't been > fed upstream, why not and is there any plan to do so? We have offered in the past but the upstream community didn't seem interested in having a PKCS#11 engine at the time. > I have no philosophical reason for this. It would be nice if it were > possible to > build my own custom OpenSSL that could exploit those processors but also > with immediate support for the latest security fixes. (For example, OpenSSL > 0.9.8n includes fixes for CVE-2010-0740 and CVE-2010-0433.) From what I > see, compiling OpenSSL with the pkcs11 engine would need to be done, so > how difficult is this? Why can a regular end user not include this > engine when compiling OpenSSL from source? It is possible to do this you can get the source of the engine from here http://blogs.sun.com/janp/ > Finally, my last question is...what other options exist for OpenSSL to > use the > Niagara crypto processors? I want to exploit hardware already present > on the > CPUs as opposed to purchasing a new hardware accelerator. Use PKCS#11 directly in userland or use the crypto_*() API (usually called KCF) in kernel. -- Darren J Moffat
