Re: cvs commit: openssl/crypto/bn bn.h bn_exp.cbn_exp2.cbn_gcd.cbn_lib.c bn_mont.c bn_mul.c bn_prime.c bn_recp.cbn_shift.cbn_sqr.cbntest.c

[Richard Levitte - VMS Whacker]

From: Ben Laurie <[EMAIL PROTECTED]>

ben> > It does mean exactly that.  If we want to constify the API, what
ben> > choice do we have?  Also, note that in the problematic sections,
ben> > there's a check to see that the BIGNUM data isn't flagged as static.
ben> 
ben> It is absolutely unacceptable to take a const argument and then modify
ben> it! I can see no reason why you'd want to, either.

The 15% performance decrease that was mentioned?

ben> > This *is* a conflict between the wish to constify and efficiency.  If
ben> > you have some elegant solution, please tell us.
ben> 
ben> If efficiency prevents you from constifying, then that's just the way it
ben> is. We need efficiency more than we need memory to not be written.

The consequence of this is that we then can't constify anything that
uses the BN functions, directly or indirectly.

What went on when I experimented was that I started of trying to
constify the RSA API, and it rippled down all the way down to
BN_mul().

At the same time, we have experienced problems with the lack of
constness (I recall Geoff mumbling about it a number of times, and
I've run into it a couple times).

This feels very much like a lose-lose situation.  We lose one of (a)
efficiency, (b) elegance in API constness and (c) strictness around
constness.


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...



And oh, you may not have noticed, but the unconstification carried to
a couple of other places.  One of them is in the ASN.1 macros, but if
I understood Stephen right, the new ASN.1 code he's working on will
take away that problem (Stephen, I'd like to hear you confirm or deny
this, so I actually know).  The other places are simply my arbitrary
choice to stop the rippling down at those points until I make further
work on this.  Those are marked with a /* TMP UGLY CAST */ and will be
removed when I get to them.

-- 
Richard Levitte   \ Spannv�gen 38, II \ [EMAIL PROTECTED]
Chairman@Stacken   \ S-168 35  BROMMA  \ T: +46-8-26 52 47
Redakteur@Stacken   \      SWEDEN       \ or +46-709-50 36 10
Procurator Odiosus Ex Infernis                -- [EMAIL PROTECTED]
Member of the OpenSSL development team: http://www.openssl.org/
Software Engineer, Celo Communications: http://www.celocom.com/

Unsolicited commercial email is subject to an archival fee of $400.
See <http://www.stacken.kth.se/~levitte/mail/> for more info.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]