On Wed, Nov 08, 2000 at 02:01:11PM +0100, Richard Levitte - VMS Whacker wrote:

[...]
> Also, the problem at hand does not really change the BIGNUM data.  It
> extendes the space the data and fills in with 0 after the actual
> number, everything so two BIGNUMs get the exact same length of data.
> It's also a rather special case, where the difference in the size of
> the numbers is one word.  I personally thought that special case would
> happen so seldom that the memory allocation overhead would be
> discardable.  I was apparently wrong on that point.
> 
> So, there's a choice to be done:
> 
>     1. revert the constness work I've done so far and live with the
>        backdraws a constless API carries.
>     2. Break constness in this particular case.
>     3. Redo BN_mul() so it retains efficiency but is constified and
>        keeps strictly to the constness.
>     4. ... something else...

The BN_mod_exp functions can be constified.  The worst that can happen
is that they'll have to copy the number that is to be exponentiated
(the BN_CTX can be used for this).

It's different for BN_sqr, BN_mul, BN_mod_mul_montgomery and the like
since those may have to expand the input values for efficiency
reasons, and since they are called hundreds of times for a single
exponentiation.
 
> And oh, you may not have noticed, but the unconstification carried to
> a couple of other places.

Constifying just the BN_mod_exp's should be enough for a lot of that.
If necessary, we can still add a constified variant of BN_mul that
copies its arguments or uses a multiplication algorithm that does not
require expansion.  (You certainly don't want an implicit BIGNUM
expansion to happen when sharing constants between threads.
Sure, race conditions can be very interesting, but still I don't like
to have them in my programs :-)


-- 
Bodo M�ller <[EMAIL PROTECTED]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. +49-6151-16-6628, Fax +49-6151-16-6036
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to