Jason Burrell wrote:
> NSS supports PKCS#11 which most hardware crypto accelerators (including > things like smartcards and offloading coprocessors) use. As far as I > know, the only OpenSSL PKCS#11 library is external to it, from the > OpenSC people. Hmm... Are the relevant kernel drivers and interfaces in place for PKCS#11 for any of the crypto offload engines discussed (Kirkwood, Tegra, Freescale)? Can somebody point me at the relevant interface docs?Generally, the CPU-based "crypto" hardware is actually just a few acceleration functions, so you don't usually access it through PKCS#11. I know NSS supports the Intel AES instructions directly (not via PKCS#11), so it should be possible to add others as well.
Accelerating instructions are something for the compilers and assemblers to deal with. I was specifically talking about asynchronous offload engines that ARM SoCs often to have.
So are you saying that the number of organizations that _don't_ use OpenSSH, OpenLDAP, mod_ssl, etc. is greater than those that do (limiting the field here to those that use some unix-like OS)? That would surprise me if it really is the case.I don't have figures as to the number of deployments of any of those tools, but only OpenSSH is listed as not yet supporting NSS anyway.
I do think there are many deployments of OpenSSL that aren't following its license's advertising requirements. As you stated, OpenSSH is used pretty much everywhere, but I don't even remember the last time I saw a statement saying a product included software from OpenSSL, except in hidden about boxes, which isn't what a clear reading for the Four-clause BSD license states.
Just out of interest, have OpenSSL maintainers complained at having just about every distribution on the planet break their licencing terms?
Gordan
Quoting Gordan Bobic gordan@bobich.net:
Jason Burrell wrote:
> NSS supports PKCS#11 which most hardware crypto accelerators (including > things like smartcards and offloading coprocessors) use. As far as I > know, the only OpenSSL PKCS#11 library is external to it, from the > OpenSC people. Hmm... Are the relevant kernel drivers and interfaces in place for PKCS#11 for any of the crypto offload engines discussed (Kirkwood, Tegra, Freescale)? Can somebody point me at the relevant interface docs?Generally, the CPU-based "crypto" hardware is actually just a few acceleration functions, so you don't usually access it through PKCS#11. I know NSS supports the Intel AES instructions directly (not via PKCS#11), so it should be possible to add others as well.
Accelerating instructions are something for the compilers and assemblers to deal with. I was specifically talking about asynchronous offload engines that ARM SoCs often to have.
There are kernel options for both synchronous and asynchronous crypto optimisation at least on the intel side in the .39 kernel. I'm unsure whether that made it back to the ARM side or not. I didnt rereun the config with ARM options.
On Wednesday, May 25, 2011 10:39:04 AM Gordan Bobic wrote:
Just out of interest, have OpenSSL maintainers complained at having just about every distribution on the planet break their licencing terms?
Gordan
thats a question best asked on a openssl list. this thread really is off-topic here, a much better place in a fedora context is devel@lists.fedoraproject.org thats where the discussions happen that effect the changes in the distro that would be needed to support what your talking about.
This list is more for user support and talking about development issues in getting fedora on arm running, what your talking about is changes to things that would effect the whole fedora ecosystem and as such belong in the bigger forum of devel@ for changes to be effected in fedora arm they must be effected in fedora as a whole.
Dennis
-
Dennis Gilmore -
Gordan Bobic -
omalleys＠msu.edu