-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ADD: support for the ed25519 curve #8
base: main
Are you sure you want to change the base?
Conversation
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:
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. But then, this would mean changing the Go version.
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 |
@schollz Perhaps it would be safer - and end in the, easier - for @thearchitector Would you be able to submit a PR to get |
@yonas great idea, I encourage you to submit a pr |
So I doubt a PR to re-implement this in stdlib would be accepted by Google. Edit: FWIW, crypto/ecdh implements X25519:
I'm not entirely sure how Based on what crypto/internal/edwards25519 says, though, it seems like filippo.io/edwards25519 is the correct way to go. |
From Google's documentation, they deprecated low-level usage of the So That leaves the filippo one as the only viable option. |
so it sounds like the only thing standing in our way here is "why doesn't the math always work?" 😛 |
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ᵤ
andZᵥ
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