I thought that in this case it was simply a matter of using the existing
CRYPTO_LOCK_RSA. I had a look at the other few references and can't see any
way that a deadlock could occur due to this reuse. Or is this lock only
supposed to be used for thread-safe reference counting?
Since the use of these locks can already be enabled/disabled at
compile-time, I don't think that the flags are required, or am I missing
something here?
Steven
> -----Original Message-----
> From: Geoff Thorpe [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, December 14, 2000 8:09 PM
> To: [EMAIL PROTECTED]
> Subject: Re: My patch to rsa_eay.c didn't seem to get accepted
>
> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
