Re: Chrome: From NSS to OpenSSL
Ryan Sleevi a écrit : That was an interesting rant, thanks. 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 don't believe that PKCS#11's threading design mandates that. Implementation easily can have that problem, and NSS sure does, but I think it would be possible to design a PKCS#11 implementation than let's you do hashing without requiring locks. Or maybe, it's more because of PKCS#11 session management rules that you hardly can avoid them. [...] 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. More or less. Already with HSM there's some serious performance concerns, and it's probably quite related to what you describe. And for smart cards, there's the fact that's it's a particularly error prone interface. All PKCS#11 code that I know that's been tested to interfaces with many cards/HSM has a very large number of quirks to run around various failures or buggy behaviors. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 08/04/14 13:11, Jean-Marc Desperrier wrote: Ryan Sleevi a écrit : 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 don't believe that PKCS#11's threading design mandates that. Implementation easily can have that problem, and NSS sure does, but I think it would be possible to design a PKCS#11 implementation than let's you do hashing without requiring locks. Or maybe, it's more because of PKCS#11 session management rules that you hardly can avoid them. If you do all your hashing in one session, then the rules require you to use locks. The obvious answer is don't do that then, but PKCS#11 libraries for dumb devices are allowed to only support a limited number of sessions and force you to juggle C_GetOperationState/ SetOperationState. But if https://developer.mozilla.org/en/docs/PKCS11_FAQ is accurate, it will only fall back on the single session solution if the device requires it. And for hashing without secret keys (plain digest, not HMAC, no C_DigestKey calls), there's never any reason to use a limited device for that operation. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Chrome: From NSS to OpenSSL
On 04/08/2014 06:31 AM, Alan Braggins wrote: On 08/04/14 13:11, Jean-Marc Desperrier wrote: Ryan Sleevi a écrit : 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 don't believe that PKCS#11's threading design mandates that. Implementation easily can have that problem, and NSS sure does, but I think it would be possible to design a PKCS#11 implementation than let's you do hashing without requiring locks. Or maybe, it's more because of PKCS#11 session management rules that you hardly can avoid them. If you do all your hashing in one session, then the rules require you to use locks. The obvious answer is don't do that then, but PKCS#11 libraries for dumb devices are allowed to only support a limited number of sessions and force you to juggle C_GetOperationState/ SetOperationState. But if https://developer.mozilla.org/en/docs/PKCS11_FAQ is accurate, it will only fall back on the single session solution if the device requires it. And for hashing without secret keys (plain digest, not HMAC, no C_DigestKey calls), there's never any reason to use a limited device for that operation. To be clear, for any token that supports multiple sessions, NSS only grabs an uncontended session lock. NSS does that not because of PKCS #11 semanatics, but because applications sometimes gets the threading wrong. If you are contending on that lock it's because the application messed up and tried to do two operations on the same context at the same time. The lock isn't grabbed because it's needed by NSS, only because applications get this kind of thing wrong a lot. Same with the NSS locks in SSL. bob smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
