x/crypto/ed25519: add montgomery/edwards key conversion #20504
Comments
CL https://golang.org/cl/44334 mentions this issue. |
The linked CL is marked DNR so I won't look too closely, but I think those functions could reasonably go into the ed25519 package. |
@agl I didn't want people to review it too closely until we'd had a chance to chat about the API and what fits where, but the little bit that's there which I started as an experiment does work. How do you feel about the "Open questions" above (or the API in general)? |
Marked as accepted, leaving @agl and @SamWhited to work out details. |
Relatedly, I'm seeing more and more projects built on the ed25519 curve as a general group setting [1][2][3]. I needed interoperability with magic-wormhole for another project of mine, and thus recently wrote a version of ed25519 (using @agl's internal field math) that satisfies the elliptic.Curve interface: https://github.com/gtank/ed25519 How would you all feel about exposing an ed25519 Curve? For example, lifting the field operations and a group interface into |
I would also find this useful, but if I understand what you're proposing it's orthogonal to this issue.
I also think this would be sensible, but I'd rather not have the scope of this proposal creep into reworking the ed25519/curve25519 packages to fit the more standard interface or to creating a full eddsa package. If AGL wants that to be done though, this proposal could surely wait for that API to exist first. |
@agl ping, the open questions could still use your consideration. If this isn't something you want to do or have time for, I will close this for now since I'm done with the project I needed it for. Let me know; thanks! |
I'm afraid this is fairly far down my Go tasks for 1.10 and unlikely to happen if people are waiting for me to do it. |
@agl I'm happy to do the work, I just want to make sure the API is something you're comfortable with. |
Is there any progress on this issue? It would be very useful if this package can provide this function. |
Private key conversion from curve25519 to ed25519 is not possible since the private scalar of curve 25519 is an intermediate value of computing the signature generated by applying SHA512 as KDF to the ed25519 private key: https://github.com/golang/crypto/blob/master/ed25519/ed25519.go#L130-L135 ToMontgomery would be more useful if you want to use the same keys for signing and ECDH. It looks like the proposed change only implements FromMontgomery: |
Is there any progress on this? I'm looking for the functionality like this: https://libsodium.gitbook.io/doc/advanced/ed25519-curve25519 |
I have also found an implementation here: https://godoc.org/github.com/agl/ed25519/extra25519 |
@FiloSottile Since Meanwhile, @agl's extra25519 has implemented Elligator 2 to generate x25519 public keys with uniform representatives. The process also involves conversion from ed25519 to x25519. Unfortunately @agl's blog post endings did not show (much?) confidence in the implementation. Having public keys with uniform representatives is very useful. If possible could we have this ability in |
That's definitely a separate issue, and I would strongly recommend ristretto255 for that use case. |
@FiloSottile Thanks for the suggestion! Would you recommend https://github.com/gtank/ristretto255 or something else for now? The API is a bit low-level (like edwards25519) and scaring for non-cryptographers to use. |
That's the implementation I worked on, which I think is reasonably robust.
We should definitely add examples, but Encode, Decode, FromUniformBytes,
ScalarMult, and ScalarBaseMult should be the only APIs you'll need.
… |
@FiloSottile Great! Filippo-approved crypto is highly appreciated! :) |
Especially now @agl has removed |
I have created |
I would like to start building an XEd25519 implementation.
XEd25519 is a signature algorithm that is fully compatible with Ed25519. It gives you the ability to use the same key for signing and ECDH. I'd like to start by implementing the conversion between points on the equivalent Montgomery and Edwards curves in the
golang.org/x/crypto/ed25519
package:It is currently difficult to do this outside of the x/crypto codebase because the
edwards25519
package is internal (and this is where all the subtle math that I don't want to reimplement lives). If it is not desirable to have this conversion be in the x/crypto package, an alternative might be moving theedwards25519
package up a level to make it public (and adding a comment that indiciates that the API is not stable, and maybe never will be; this feels poor though).Open Questions
xeddsa
package in casecurve448
support is implemented later and we want to generalize the implementation over both curves? Or maybe this should only be for if a full xeddsa implementation (not just key conversion) is ever implemented.PublicKey
andPrivateKey
types to thecurve25519
package and assume these are always in montgomery format? It would add a dependency loop that would have to be resolved, but might make the API nicer./cc @agl
The text was updated successfully, but these errors were encountered: