10:39 a.m.
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
11:08 a.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
Quoting Gordan Bobic <gordan(a)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.
11:47 a.m.
New subject: Hardware Crypto Offload on Kirkwood (SheevaPlug)
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(a)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
4719
days inactive
4719
days old
2 comments
3 participants
participants (3)
-
Dennis Gilmore -
Gordan Bobic -
omalleys＠msu.edu