schollz
ADD: support for the ed25519 curve
This PR adds support for the edwards25519 curve using the filippo.io/edwards25519 package (the public release of the low-level package used internally by the Go std lib).
@schollz I'm making this a draft PR because I'm running into some weirdness for which I don't have the Go nor EC mathematical background to understand (my experience with both extends only as far as this tool and PR). From what I can tell, there's something about the random scalars that cause it to incorrectly generate the Zᵤ and Zᵥ coordinates (they don't match). If you pin both the scalar values to known working ones, it always succeeds. If you pin one of them to a known failing one, it always fails. It feels like a mathematical property of some sort, but I looked at the integer values, byte values, and bit strings of the scalars and can't seem to figure out the misbehaving pattern.
Any input would be appreciated so that this (and by extension, croc) can support this curve
@schollz @tscholl2 I'm still interested in getting this working, if either of you have the capacity to take a look.
I'll say that more recent versions, since 1.20rc1, of Go already support ed25519.
If this project can be updated, then that extra package won't be needed anyway.
I'll say that more recent versions, since 1.20rc1, of Go already support ed25519.
If this project can be updated, then that extra package won't be needed anyway.
are you referring to crypto/ed25519? on 1.22.4 (latest), that package doesn't expose any arithmetic functions, and relies on crypto/internal/edwards25519 to do the math; that internal package says:
However, developers who do need to interact with low-level edwards25519 operations can use filippo.io/edwards25519, an extended version of this package repackaged as an importable module.
which is why I'm using that library here.
Well, why not actually use the built-in crypto/internel/edwards25519 like you mentioned?
The notes also said the filippo.io one is not covered by Go 1 Compatibility Promise. Wouldn't it be better to use the more guaranteed to remain compatible one?
But then, this would mean changing the Go version. I would recommend 1.19.7 to 1.19.13 or 1.20.2 onwards.
Due to GO-2023-1621, there's a problem with P256 so versions 1.19beta1 to 1.19.6 and 1.20rc1 to 1.20.1 should be avoided.
This would be the case to refactor the NIST curves to use crypto/internal/nistec due to changes in Go crypto.
@thearchitector thanks so much for this pr, sorry it took so long to get to it, will try to figure out whats going on
@joshcangit, the crypto/internel/edwards25519 does not have IsOnCurve, a necessary function for what we are doing here, so it is not used.
the crypto/internel/edwards25519 does not have IsOnCurve, a necessary function for what we are doing here, so it is not used.
@schollz Perhaps it would be safer - and end in the, easier - for IsOnCurve to be imported into crypto/internel/edwards25519.
@thearchitector Would you be able to submit a PR to get IsOnCurve merged into the standard library?
