On 05/25/2011 12:06 PM, Gordan Bobic wrote:
Andrew Haley wrote:
>> I'm not against NSS - really I'm not. But there are other considerations
>> to be taken into account.
>> 1) 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
> 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.
Definitely, which is why it's important to focus on the right library
>> 2) More abstraction (a OpenSSL->NSS shim library), means
>> more context switching and less performance. Is that really the way
>> forward? I mean _really_?
> For bulk crypto operations an extra call via a shim probably doesn't
> matter. For some signature operations it might.
> It seems like a clean solution from the point of view of application
> developers, though.
The other thing that needs to be considered is added complexity and
security. I would imagine that since there is an abstraction layer, it
introduces additional scope for exploits (buffer overruns, stack
smashing, etc.) Is this shim library going to also be FIPS certified? If
not then the improved security aspect of NSS vs. OpenSSL comes a lot
closer to pure marketing rhetoric (maybe that's where it's at at the
moment anyway, I don't claim to be an expert on the subject).
Perhaps, but all this is just speculation AFAICS. If a shim is
unnecessary then it should be avoided, obviously.
>> 3) Volume of supported commonly used software - if NSS has a
>> 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
I thought it was mentioned on this thread recently that GPG brings it's
own implementation anyway. Did I misunderstand?
It does, but I was responding to the claim that OpenSSL was being used
for everything you touch on a daily basis. If that was not what you
implied, I apologize. But if most crypto apps are using home-baked
library code, then it doesn't matter which crypto library we move to
because most apps will need to be ported anyway.
> But the real question is whether one group of Fedora developers
> 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.
It's a sight more happy than two groups of Fedora developers fighting
over the One True Crypto Library. IMO. :-)
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
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.
I think it's a mistake to characterize one set of developers as more
pragmatic than the other. If we end up with a highly-performant
crypto library that some Fedora packages can't be linked against for
legal reasons, that would be -- pragmatically speaking -- a Very Bad