I think this whole thread is getting a little out of hand. It was
mentioned initially about using other libraries instead of built in
routines in gpg.
>> 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
>> today).
There's lots of reference to HW offload on NSS. For one its explicitly
mentioned in referenced Fedora consolidation [1], in the NSS FAQ [2]
and wikipedia [3] :-)
So its a matter of seeing how that integrates and fits with the the
linux kernel crypto api as that would be the obvious place to add the
support as if the HW is there it will get used and it would also get
access to any cpu acceleration that is not crypto specific (I've read
about using NEON for this for example).
[1]
http://fedoraproject.org/wiki/FedoraCryptoConsolidation#Technology_selection
[2]
https://developer.mozilla.org/en/NSS_FAQ
[3]
http://en.wikipedia.org/wiki/Network_Security_Services#Hardware_support
> 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).
Remember this needs to be upstream in Fedora and other projects and
then Fedora ARM will get it by default. Work upstream, propose it as a
Fedora 16 feature and do the work.
I don't think its particularly important to ARM. It certainly helps on
ARM due to low processing but its relevant on all platforms and most
platforms have some form of crypto offload built in to the core CPU
now days. Hell even the AMD geode processor used in the XO has it.
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.
Working in hosting myself with massive amounts of SSL offload we're
not exactly looking at arm. There's lots of other issues here, and
none of them are specific to ARM processors.
>> 2) More abstraction (a OpenSSL->NSS shim library), means
more bloat,
>> 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).
Read the details mentioned on the advantage of NSS over OpenSSL for
FIPS certification on the consolidation wiki.
>> 3) 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?
Yes, that's why we ended up in the discussion of types of libary!
> 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.
NSS supports HW. See above. All things need to be dealt with upstream.
Whether it be Fedora, kernel, NSS or other apps.
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.
The consolidation proposal was (I believe) instigated by the team(s)
in Red Hat that deal with crypto and the various certifications
required by an OS and applications that require things like FIPS cert,
HW offload by customers that run platforms that require large
encryption capabilities etc so I'm sure they've done a lot of work in
that direction and made the proposal for a reason. I remember there
was a lot of discussion on devel@ when it was proposed. I suggest you
dig out those discussions.
As such support for crypto HW support in what ever libraries is better
reported as a bug against the associated components. This list is
about supporting ARM as a secondary architecture with in Fedora not
about specific HW support in libraries. We will always use upstreams
implementation of that. We have more than enough to do to support
Fedora as a distro on ARM :-)
Peter