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
