Jason Burrell wrote: > On May 25, 2011 6:06 AM, "Gordan Bobic" <gordan@xxxxxxxxxx > <mailto:gordan@xxxxxxxxxx>> 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 > > >> 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? > > >> 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? > > > > > 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 _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
