without success.

really the square of the return value.

the new method names where _GF... suffixes have been removed.

Revert changes to ..._{get/set}_Jprojective_coordinates_...:
The current implementation for ECC over binary fields does not use
projective coordinates, and if it did, it would not use Jacobian
projective coordinates; so it's OK to use the ..._GFp prefix for all
this.

Add author attributions to some files so that it doesn't look
as if Sun wrote all of this :-)

The 'OPENSSL_NO_SUN_DIV' default is still subject to change,
so I didn't bother to finish the CHANGES entry yet.

Submitted by: Douglas Stebila <douglas.stebila@sun.com>, Sheueling Chang <sheueling.chang@sun.com>
(CHANGES entry by Bodo Moeller)

happens reliably, even if the BIGNUM is already sufficiently large.

[Note that the bn_expand()/bn_wexpand() macros call bn_expand2() only
if the BIGNUM actually has to grow, so this change does not add any
new overhead as currently bn_expand2() is never called directly.]

handled properly.
Part of PR 75

PR: 75

PR: 49

Fallback to normal multiply if n2 == 8 and dna or dnb is not zero
in bn_mul_recursive.

This is (hopefully) what was triggering bignum errors on 64 bit
platforms and causing the BN_mod_mul test to fail.

Avoid gcc warning: BN_DEC_CONV when SIXTY_FOUR_BIT is defined is unsigned.

Submitted by: Nils Larsch

perl util/mkerr.pl -recurse -write -rebuild

Submitted by: Toomas Kiisk <vix@cyber.ee>

(by using new BN_pseudo_rand_range function)

HP-UX in common in ./config). Note that for the moment of this writing
none of 64-bit platforms pass bntest. I'm committing this anyway as it's
too frustrating to patch snapshots over and over while 0.9.6 is known to
work.

I was wrong in conclusions about when addition starts overflowing in combaX
routines.

Submitted by:
Reviewed by:
PR:

Submitted by:
Reviewed by:
PR:

details (performance numbers and accompanying discussions:-). Note that
the code is not engaged in ./Configure yet. I'll add it later this week
along with updates for .spec file.

Submitted by:
Reviewed by:
PR:

Ultra-Sparcs (both 32-bit and 64-bit compilations)

Submitted by:
Reviewed by:
PR:

It does not appear to be faster than the current Montgomery code
except for very small moduli (somewhere between 192 and 224 bits
in a 64-bit Sun environment, and even less than 192 bits
on 32 bit systems).