so we have to reduce the random numbers used in test_mont.
Before this change, test_mont failed in [debug-]solaris-sparcv9-gcc
configurations ("Montgomery multiplication test failed!" because
the multiplication result obtained with Montgomery multiplication
differed from the result obtained by BN_mod_mul).
Substituing the old version of bn_gcd.c (BN_mod_inverse) did not avoid
the problem.
The strange thing is that it I did not observe any problems
when using debug-solaris-sparcv8-gcc and solaris-sparcv9-cc,
as well as when compiling OpenSSL 0.9.6 in the solaric-sparcv9-gcc
configuration on the same system.
This caused a segmentation fault in calls to malloc, so I cleaned up
bn_lib.c a little so that it is easier to see what is going on.
The bug turned out to be an off-by-one error in BN_bin2bn.
- Add "-cipher" and "-out_state" command line arguments to control SSL
cipher-suites and handshake debug output respectively.
- Implemented error handling for SSL handshakes that break down. This uses
a cheat - storing a non-NULL pointer as "app_data" in the SSL structure
when the SSL should be killed.
the RSA_METHOD's "init()" handler is called, and is cleaned up after the
RSA_METHOD's "finish()" handler is called. Custom RSA_METHODs may wish to
initialise contexts and other specifics in the RSA structure upon creation
and that was previously not possible - "ex_data" is where that stuff
should go and it was being initialised too late for it to be used.
These new files will not be included literally in OpenSSL, but I intend
to integrate most of their contents. Most file names will change,
and when the integration is done, the superfluous files will be deleted.
Submitted by: Lenka Fibikova <fibikova@exp-math.uni-essen.de>
I'm a little bit nervous about bn_div_words, as I don't know what it's
supposed to return on overflow. For now, I trust the rest of the
system to give it numbers that will not cause any overflow...
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!
