When calling a Microsoft cryptographic service provider (CSP), certain characteristics related to threads need to be taken into account.

Creation and deletion of the same key container across threads is not supported. The CryptAcquireContext function is generally thread safe unless CRYPT_NEWKEYSET or CRYPT_DELETEKEYSET is specified in the dwFlags parameter. The CryptGenKey function, however, is not thread safe because it performs file I/O that cannot be synchronized. To expand on the issue, consider that an operation that modifies a key container, such as the creation of a new key pair, results in file I/O operations that cannot be synchronized across multiple processes. For this reason, applications should never use the default key container. Applications that do not require access to persisted key pairs should always call CryptAcquireContext with CRYPT_VERIFYCONTEXT specified in the dwFlags parameter. A benefit is a performance gain because no file I/O operations are performed. Similarly, applications that need a temporary public/private key pair can also use the CRYPT_VERIFYCONTEXT flag. Multiple threads can safely perform any CryptAcquireContext operations against different containers.

Most algorithms and modes require that data be decrypted in the same order that it was encrypted. This is a difficult task in a multithreaded environment because use of a critical section will not address the ordering issue. If you are using a block cipher (that is, RC2, DES, or 3DES) in ECB cipher mode, then this issue is not a factor because the internal key state does not change. However, ECB is not the default cipher mode. CBC is the default cipher mode. With CBC cipher mode, the internal key state does change.

After a key handle has been obtained by using the CryptGetUserKey function, RSA signing and signature verification are thread safe.

Send comments about this topic to Microsoft

Build date: 6/26/2009