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
