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
_______________________________________________
crypto-discuss mailing list
crypto-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/crypto-discuss
