| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
ok jsing
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The only way to get an EC_GROUP or an EC_POINT is by calling the relevant
_new() function and to get rid of it, something must call _free(). Thus we
can establish the invariant that every group has Weierstrass coefficients
p, a, b as well as order and cofactor hanging off it. Similarly, Every
point has allocated BIGNUMs for its Jacobian projective coordinates.
Unfortunately, a group has the generator as an optional component in
addition to seed and montgomery context/one (where optionality makes
more sense).
This is a mostly mechanical diff and only drops a few silly comments and
a couple of unnecessary NULL checks since in our part of the wrold the
word invariant has a meaning.
This should also appease Coverity who likes to throw fits at calling
BN_free() for BIGNUM on the stack (yes, this is actually a thing).
ok jsing
|
| |
|
|
|
|
|
|
|
|
|
| |
This had an extra dance to allow a NULL output buffer. The plan was to
use this in i2o_ECPublicKey() to preserve the behavior of avoiding an
allocation if out == NULL. However, when I rewrote the latter I punted
on preserving that complication, as it was already batshit crazy enough.
Thus, remove said dance and make ec_point_to_octets() cleaner.
ok jsing
|
| |
|
|
|
|
| |
Now that we only do curves over GF(p) fields, there's no need to use a
weird, confusing name for what we usually call p. Adjust some comments
in the vicinity as well.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
EC_POINT_oct2point() is the only API that needs detailed knowledge about
this incomplete enum. [Arguably, the setters for the EC_KEY and EC_GROUP
member of that type would also need to be able to validate what's being
set, but they can't since they can't fail.] Anyway. Add a helper that lets
EC_POINT_oct2point() translate that enum to its internal representation
at the API boundary and add a check that ensures that we only encode the
point at infinity as the point at infinity.
ok jsing
|
| |
|
|
|
|
|
| |
With the functions living in ec_convert now, the oct makes little sense.
And ec_oct_oct2point() was too much for poor jsing to bear.
requested by jsing
|
| |
|
|
|
|
|
|
| |
Both our remaining EC_METHODs use the methods that used to be called
ec_GFp_simple_{oct2point,point2oct}() so there's no need for the function
pointer indirection. Make the public API call them directly.
ok jsing
|
| | |
|
| | |
|
| |
|
|
| |
discussed with jsing
|
| | |
|
| |
|
|
| |
discussed with jsing
|
|
|
discussed with jsing
|
