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 >>> 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. Definitely, which is why it's important to focus on the right library going forward. >>> 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). 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 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? 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 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. 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 > great idea. Right. > 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 Thing. Andrew. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
