On September 25, 2003 03:33 am, Nils Larsch wrote:
> Otto Moerbeek wrote:
> ....
>
> > OK, that would amount to the fixes below:
> >
> > - in BN_cmp, call bn_fix_top just before comparing the two tops.
>
> Not really necessary as the normal BN_* functions which change the
> value of the bignum should always ensure that the top value is
> correct (i.e. as small as possible), but of course adding bn_fix_top
> does not really harm (besides wasting some cpu time :-) .

I would go one step further and suggest that BN_cmp() and operations like 
it that should treat their inputs as "const" should not modify the 
BIGNUMs at all. Fixing BIGNUMs wherever we spot problems helps propogate 
the current mess, the correct fix (as Nils implied) is to trace the 
problem back to where it is caused and fix it there. No BIGNUM structure 
should ever be in an invalid state outside the scope of a BN_*** API 
function (or macro). So each function should, on exit, have correctly 
adjusted any data as necessary.

Perhaps (any volunteers?) the best way to do this would be to define a 
validation function/macro and call it from every exit path for every 
BIGNUM API function and macro. This could sanity-check the in/out 
variables and abort() if there's something wrong so that the debugger can 
catch these problems where they occur rather than where we first notice 
them (later on in things like BN_cmp). IMHO this would be infinitely more 
useful than continually adding calls to bn_fix_top() everywhere it seems 
it could seal off another "case".

> Perhaps you should send a bug report to [EMAIL PROTECTED] containing the
> patch and a link to this thread.

Yup, this should certainly go into RT - but I think this would be the 
ideal opportunity to audit the BIGNUM code properly for this sort of 
thing. In particular, it would be nice if the result of this work would 
also allow us to better constify the BIGNUM API (in CVS HEAD of course, 
the stable branches would merely benefit from cleaner implementations;-).

Cheers,
Geoff

-- 
Geoff Thorpe
[EMAIL PROTECTED]
http://www.geoffthorpe.net/

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [EMAIL PROTECTED]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to