kklash / ekliptic Goto Github PK

Basically it would just call AddAffine or AddJacobian while negating the input point.

Golang's standard library provides an elliptic curve crypto utility:

$ go doc elliptic.curve

package elliptic // import "crypto/elliptic"

type Curve interface {
	// Params returns the parameters for the curve.
	Params() *CurveParams
	// IsOnCurve reports whether the given (x,y) lies on the curve.
	IsOnCurve(x, y *big.Int) bool
	// Add returns the sum of (x1,y1) and (x2,y2)
	Add(x1, y1, x2, y2 *big.Int) (x, y *big.Int)
	// Double returns 2*(x,y)
	Double(x1, y1 *big.Int) (x, y *big.Int)
	// ScalarMult returns k*(Bx,By) where k is a number in big-endian form.
	ScalarMult(x1, y1 *big.Int, k []byte) (x, y *big.Int)
	// ScalarBaseMult returns k*G, where G is the base point of the group
	// and k is an integer in big-endian form.
	ScalarBaseMult(k []byte) (x, y *big.Int)
}
    A Curve represents a short-form Weierstrass curve with a=-3.

    The output of Add, Double, and ScalarMult when the input is not a point on
    the curve is undefined.

    Note that the conventional point at infinity (0, 0) is not considered on the
    curve, although it can be returned by Add, Double, ScalarMult, or
    ScalarBaseMult (but not Unmarshal or UnmarshalCompressed).

We should provide a struct which fulfills this interface, so callers can use it in golang standard library APIs.

Possibly related: if we have an elliptic.Curve, we can get rid of ekliptic.NewPrivateKey, because callers could just use crypto/elliptic.GenerateKey instead:

package elliptic // import "crypto/elliptic"

func GenerateKey(curve Curve, rand io.Reader) (priv []byte, x, y *big.Int, err error)
    GenerateKey returns a public/private key pair. The private key is generated
    using the given reader, which must return random data.

Github actions, probably.

• Run linter
• Run unit tests
• Run benchmarks?

• More examples of how to use this code, in human readable terms (#11)
• Add custom artwork for the library
• Publish a link to pkg.go.dev in readme (9e6b550)

0000000000000000000000000000000000000000000000000000000000000001
vs
6d1b68d0dd35b49978b210349b47202a998d0eaaa4eec00b4d8f056173a2dd4e

is easier to compare visually than

1
vs
6d1b68d0dd35b49978b210349b47202a998d0eaaa4eec00b4d8f056173a2dd4e

It would be nice to compare some our high-level operations like ECDH or base-point multiplication against Go's builtin ECC logic.

Test vectors are rather opaque right now as to where they came from and how I got them. We could write scripts to re-derive (thus validating) our test vectors using other stable secp256k1 implementations.

Potential side-quest related to this issue: in EC math unit tests, we should check affine equality against vectors rather than jacobian equality. It doesn't matter in the end what the exact (x,y,z) pair is, as long as the jacobian ratio is equivalent to the desired affine point. Testing affine equality will make it easier to consume the test vectors of other implementations, because they may use different jacobian math than us.