implement ed25519 support #5
Conversation
| if !ok { | ||
| t.Fatal("signature didnt match") | ||
| } | ||
| } |
There was a problem hiding this comment.
Other basic test case is that signatures of wrong key shouldn't match.
|
ed25519 was not vendored into gx. |
|
It might be too much, but it would be great to create tests for official test vectors of ed25519 so if we change the underlying impl we are sure it will still work: https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-02#section-6 |
|
Guys, what's the status of this PR and what kind of help do you need? |
|
@vyzo we got distracted after trying to find out how to turn ed25519 keys into curve25519 keys for encrypting things. If you can figure out how that works, that would be pretty helpful |
|
Is encryption actually necessary from a protocol point of view? |
|
Also, is there any reason for not using the golang.org/crypto/ed25519 package? |
Yeah the golang one [1] seems to be the continuation of agl's [2] [1] https://github.com/golang/crypto/tree/master/ed25519 |
|
Right, the package graduated from agl's personal github to golang.org. |
|
So while digging in the agl code, I found this file: Is this what you were looking for? Note: sadly the extra25519 subpackage is not included in the golang.org package. |
|
@vyzo No, encryption isnt required as part of the interface. I don't believe we use it anywhere, but it would be a nice to have down the road. We can shrink the interface for now, and when we get to the point where we need it we can finish this stuff |
|
@whyrusleeping shrinking the interface for quick merging sounds great, we really want ECC keys! |
|
Anything we can do to help get this merged in? We're blocked by this and happy to help out |
generally i'm all for it! :) support for ed25519 keys is great because it'll also enable SHS or CryptoAuth transport-level crypto. |
lol nevermind, I see what the scope is for now :) |
|
@parkan right now the hard part is the migration path. How do we best ship this in a way that makes sense. My current thoughts are to ship this into go-ipfs, so that it enables nodes to be able to handle these keys. And then only allow generation of these keys with a special flag on init. The issue is that if your node is using an ed25519 key, you won't be able to communicate with a node who doesnt know how to handle that key. |
|
@whyrusleeping Can't it be merged into libp2p regardless of IPFS migration? |
|
@vyzo Yeap! and we're gonna do that now! (Sorry about the delay, chinese internet is super difficult) |
No description provided.