On Fri, January 31, 2014 9:18 am, Alan Braggins wrote: > On 31/01/14 10:24, Julien Pierre wrote: > > > > On 1/27/2014 10:28, Kathleen Wilson wrote: > >> Draft Design Doc posted by Ryan Sleevi regarding Chrome migrating from > >> NSS to OpenSSL: > >> > >> https://docs.google.com/document/d/1ML11ZyyMpnAr6clIAwWrXD53pQgNR-DppMYwt9XvE6s/edit?pli=1 > > > Strange that "PKCS#11 support" is listed as a "con" for NSS . > > It is at least listed under "pro" as well.... (Having ENGINE_pkcs11 > listed under both for OpenSSL might make sense too.) >
It was not accidental that it was listed under "Con", nor do I see ENGINE_pkcs11 as a "Pro" As part of its fundamental design, NSS performs all operations using PKCS#11 tokens. Even the internal cryptographic implementation is exposed as a PKCS#11 token - softoken. I realize that from a design and layering perspective, there are those (especially within NSS developers) that feel this is a Pro. However, in practical terms, this works out as a significant negative for performance. It's not "merely" the function call overhead, but the abstraction prevents significant compiler optimizations for space and size. Further, the PKCS#11 API itself - while suitable for interacting with IO contrained hardware tokens - is absolutely horrible for maximizing CPU thoroughput. Consider AES-GCM or AES-CBC-PAD. The former requires establishing a new PKCS#11 context every time, which forces levels of key expansion. I realize some NSS developers have suggested possible ways to improve this - but the engineering effort is recognized to be complex. We've also been committed to the newly-formed OASIS TC to try to improve things, but the reality is that the current spec is "broken for purpose". Or consider AES-CBC-PAD, which is essentially *the same issue*. Because of this, NSS's SSL layer only uses AES-CBC, and handles padding manually, so that it can keep a single context around for the duration of the SSL session. On the server side, NSS is virtually non-existent on any platform that deeply cares about performance because of this. Heck, there is a whole "PKCS#11 bypass" mode precisely for this. This reliance on PKCS#11 means that there are non-trivial overheads when doing something as "simple" as hashing with SHA-1. For something that is such a "simple" transformation, multiple locks must be acquired and the entire NSS internals may *block* if using NSS on multiple threads, in order to prevent any issues with PKCS#11's threading design. I tried not to write too much on the negatives of NSS or OpenSSL, because both are worthy of long rants, but I'm surprised to hear anyone who has worked at length with PKCS#11 - like Oracle has (and Sun before) - would be particularly praising it. It's good for interop with smart cards. That's about it. Cheers, Ryan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
