Remove certain redundant BN_zero() initialisations, because BN_CTX_get(),
BN_init(), [etc] already initialise to zero.
Correct error checking in bn_sqr.c, and be less wishy-wash about how/why
the result's 'top' value is set (note also, 'max' is always > 0 at this
point).
replaced #if logic around bn_sub_part_words in bn_mul.c. I rely upon
OPENSSL_BN_ASM_PART_WORDS being added by ./Configure script. Would it
still work on non-Unix platforms?
sure they are available in opensslconf.h, by giving them names starting
with "OPENSSL_" to avoid conflicts with other packages and by making
sure e_os2.h will cover all platform-specific cases together with
opensslconf.h.
I've checked fairly well that nothing breaks with this (apart from
external software that will adapt if they have used something like
NO_KRB5), but I can't guarantee it completely, so a review of this
change would be a good thing.
for its ASN1 operations as well as the old style function
pointers (i2d, d2i, new, free). Change standard extensions
to support this.
Fix a warning in BN_mul(), bn_mul.c about uninitialised 'j'.
course, that means we need to handle the cases where the two arrays to
bn_mul_recursive() and bn_mul_part_recursive() differ in size.
I haven't yet changed the comments that describe bn_mul_recursive()
and bn_mul_part_recursive(). I want this to be tested by more people
before I consider this change final. Please test away!
BN_mul() correctly constified, avoids two realloc()'s that aren't
really necessary and saves memory to boot. This required a small
change in bn_mul_part_recursive() and the addition of variants of
bn_cmp_words(), bn_add_words() and bn_sub_words() that can take arrays
with differing sizes.
The test results show a performance that very closely matches the
original code from before my constification. This may seem like a
very small win from a performance point of view, but if one remembers
that the variants of bn_cmp_words(), bn_add_words() and bn_sub_words()
are not at all optimized for the moment (and there's no corresponding
assembler code), and that their use may be just as non-optimal, I'm
pretty confident there are possibilities...
This code needs reviewing!
two functions that did expansion on in parameters (BN_mul() and
BN_sqr()). The problem was solved by making bn_dup_expand() which is
a mix of bn_expand2() and BN_dup().
but the BN code had some problems that would cause failures when
doing certificate verification and some other functions.
Submitted by: Eric A Young from a C2Net version of SSLeay
Reviewed by: Mark J Cox
PR:
