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
