Is RSACng from X509Certificate2.GetRSAPrivateKey thread-safe? #128681
-
|
I have an asp.net core web application that needs to sign a jwt using the private key associated with a certificate loaded from the windows certificate store, using code similar to this: RSA privateKey;
X509Certificate2 cert;
using (var store = new X509Store(StoreName.My, StoreLocation.CurrentUser))
{
store.Open(OpenFlags.ReadOnly);
//Locate the required 'Current' certificate using the distinguished name, and create
// the snapshot wrapper for it
var certs = store.Certificates.Find(X509FindType.FindBySubjectName, configuration.Current.SubjectName, validOnly: validCertificatesOnly);
cert = certs[0];
}
privateKey = cert.GetRSAPrivateKey();Is it safe to use the same RSA instance for signing operations on multiple threads? The call to GetRSAPrivateKey seems to be fairly expensive in terms of time (multiple milliseconds) so I'd rather not take the hit on every request, but I can't find any documentation on whether or not it's thread safe. I've also seen the RSA returned by GetRSAPrivateKey suddenly become unusable after a period of time for no apparent reason (throwing a CryptographicException with a message of 'File not found' for an instance that previously worked fine. |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
The instance members are not documented as thread-safe. The full implementation of the returned object (which is only RSACng on Windows) is an OS component which does not document itself as thread-safe, so the only way we could document the class as thread-safe is if we instilled our own locking, which we don't do. My personal belief, though not a recommendation you should depend on, is that the native implementations are thread-safe (assuming you don't parallelize the operation with Dispose), so it's "probably fine", but we (.NET) do not guarantee it, and wouldn't make any changes to our code in response to a data-corruption thread-safety bug report. |
Beta Was this translation helpful? Give feedback.
The instance members are not documented as thread-safe.
The full implementation of the returned object (which is only RSACng on Windows) is an OS component which does not document itself as thread-safe, so the only way we could document the class as thread-safe is if we instilled our own locking, which we don't do.
My personal belief, though not a recommendation you should depend on, is that the native implementations are thread-safe (assuming you don't parallelize the operation with Dispose), so it's "probably fine", but we (.NET) do not guarantee it, and wouldn't make any changes to our code in response to a data-corruption thread-safety bug report.