Jason Burrell wrote:
On May 25, 2011 6:06 AM, "Gordan Bobic" <gordan@bobich.net mailto:gordan@bobich.net> wrote:
Andrew Haley wrote:
I'm not against NSS - really I'm not. But there are other
considerations
to be taken into account.
- Does NSS have any kind of support for hardware crypto offload?
If so,
I haven't found any references to it (but maybe my google-foo is weak today).
Interesting question; not sure.
I think it is an important one to answer, and sooner rather than later. This is particularly important to the ARM community since a lot of (most?) ARMs seem to have a crypto co-processor of some description (Freescales, Kirkwood and Tegra definitely seem to have this, I haven't checked others, but since these are the three classes of devices I own, that's 3 out of 3 - I don't think it's luck/coincidence).
This is particularly important for server applications. ARM is getting some traction in the server market. ZT make a really nice (if expensive) multi-ARM server. I have seriously discussed using ShevaPlugs/GuruPlugs specifically for large scale-out low-power SSL offload with clients. Crypto offload support is already important, and it's importance is only going to go up.
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?
- Volume of supported commonly used software - if NSS has a clear
advantage in terms of support base, then so be it, let's all put our weight behind it. But my perception is that this is not the case. Everything I touch upon on a daily basis seems to be linked against OpenSSL rather than NSS.
Well, that's not true for everyone, and certainly not for users of GPG.
I thought it was mentioned on this thread recently that GPG brings it's own implementation anyway. Did I misunderstand?
But the real question is whether one group of Fedora developers is determinedly going to push NSS and the other OpenSSL. That is not a route to happiness.
It's not, but losing crypto offload and/or a performance drop-off and bloat due to shimming isn't a happy solution, either. If we can address those (the latter by sending patches to build against NSS upstream so shimming isn't required), then it'd be a great idea.
But purely in terms of standardizing on a single crypto library - has anyone actually performed an exhaustive analysis on how much would need to be changed to go either way? The wiki page that has been referenced a few times seems distinctly non-exhaustive. Maybe my perception is non-representative here, but as I said, all the things I get my hands dirty on a regular basis are linked against OpenSSL rather than NSS. The pragmatist in me says that maybe that makes OpenSSL a better target to standardize on, but I would like to see an exhaustive analysis / empirical evidence showing otherwise.
"FIPS" OpenSSL isn't the same thing as "normal" OpenSSL. From OpenSSL's own FIPS docs, "The FIPS Object Module is the special monolithic object module built from the special source distribution identified in the Security Policy. It is not the same as the OpenSSL product or any specific official OpenSSL distribution release."
So requiring FIPS (which the US gov't and many large organizations do) undermines the argument that OpenSSL is used more extensively.
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.
Gordan