On Thu, 14 Dec 2000, Richard Levitte - VMS Whacker wrote:
> From: "Reddie, Steven" <[EMAIL PROTECTED]>
>
> Steven.Reddie> I've come across four race conditions in the following
> Steven.Reddie> functions in rsa_eay.c:
> Steven.Reddie> RSA_public_encrypt
> Steven.Reddie> RSA_public_decrypt
> Steven.Reddie> RSA_eay_mod_exp (x2)
> Steven.Reddie>
> Steven.Reddie> These can cause unexpected failure of the RSA_eay_
> Steven.Reddie> encryption/decryption functions for both public and
> Steven.Reddie> private key operations. The problem occurs when more
> Steven.Reddie> than one thread simultaneously uses the same RSA key
>
> Hmm, someone else needs to tell us if this is meant to be supported or
> not for now. However, when it comes to the locking part, for now
> CRYPTO_LOCK_RSA is probably the more appropriate one, but what we
> really should have is a lock for each instance of the RSA structure
> (or any structure). I've talked about this some time ago, perhaps
> it's time to do more than just talking...
Well, this one at least would be relatively straightforward. Steven is
right (I think) that by locking the first-time initialisation of per-RSA
cached variables (montgomery stuff in this case) that basically the rest
becomes implicitly thread safe. So the obvious thing to me seems to
include a flag (RSA, DSA, and a truck load of other structures already
have a flag variable) to indicate whether these initialisations should
take place under the CRYPTO_LOCK_RSA lock or not.
By changing the flag value in the [RSA|DSA|...]_METHOD itself, the default
behaviour could be switched between "default to locking" and "default to
no locking", and then of course one still has the option to change it per
key if they choose. In fact another level up; the default flag that is
*compiled* into the ..._METHODs could also be configurable - presumably in
the same way that other locking stuff is configurable for compilation.
What d'y'all think?
Cheers,
Geoff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
