Skip to content
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 shs/350 #36

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
Open

add shs/350 #36

wants to merge 5 commits into from

Conversation

keks
Copy link
Contributor

@keks keks commented Sep 16, 2016

Here is a pull request to add the shs protocol suite designed and first implemented in JS by @dominictarr.
It is used by go-libp2p-shs.

I used protocol code 350 because it feels like it belongs below ipfs but in top of udt/utp.

@jbenet
Copy link
Member

jbenet commented Sep 16, 2016

Great! Maybe add some tests to https://github.com/multiformats/go-multiaddr/blob/master/multiaddr_test.go to make sure it encodes/decodes as expected

@keks
Copy link
Contributor Author

keks commented Sep 17, 2016

How could I forget that, done.

@@ -374,7 +382,7 @@ func TestFuzzBytes(t *testing.T) {
}

func randMaddrString() string {
good_corpus := []string{"tcp", "ip", "udp", "ipfs", "0.0.0.0", "127.0.0.1", "12345", "QmbHVEEepCi7rn7VL7Exxpd2Ci9NNB6ifvqwhsrbRMgQFP"}
good_corpus := []string{"tcp", "ip", "udp", "ipfs", "shs", "0.0.0.0", "127.0.0.1", "12345", "QmbHVEEepCi7rn7VL7Exxpd2Ci9NNB6ifvqwhsrbRMgQFP", ""}
Copy link
Member

@jbenet jbenet Sep 17, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

empty is fine? this is the good corpus so should be a valid shs addr, no?

Weird that tests pass... cc @Kubuxu

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, empty is not fine. Copypaste mistake.

I realized that the shs protocol only uses ed25519 keys, so I changed it from length prefixed var size to ed25519.PublicKeySize and added length checks in codec.go. The test still passes both with the correct and with empty string, though.

Should I import agl's ed25519 just for using that constant or should I copy it into this package? In case I should import it, how? By vendoring, gx or directly?

Copy link
Member

@jbenet jbenet Sep 18, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized that the shs protocol only uses ed25519 keys

Ahh, only ed25519? bummer

The test still passes both with the correct and with empty string, though.

yeah this is weird, and seems incorrect. @Kubuxu thoughts?

Should I import agl's ed25519 just for using that constant or should I copy it into this package? In case I should import it, how? By vendoring, gx or directly?

if its just that constant, nah, just copy it in, i think. (deps are unfortunately expensive :( )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We had similar issue in go-ipfs, even empty, no protocol maddr is a valid maddr.

Should we change it?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I realized that the shs protocol only uses ed25519 keys, so I changed it from length prefixed var size to ed25519.PublicKeySize and added length checks in codec.go. The test still passes both with the correct and with empty string, though.

is there a chance that SHS will support other key algorithms in the future? if so, it should stay variable-length. cc @dominictarr

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

short answer: no.

shs is designed to be maximally metadata private (as is reasonable). so for this reason, there is no ciphersuite negioation. That also means downgrade attacks are simply not possible.
This also means you can't change shs -- to change shs you have to change it into another protocol, and then the new protocol gets a new multiformat name.
The plan is, as you are phasing in a new protocol, you just run it in parallel, say, on a different port.
then remove it when enough of the network has upgraded.

@jbenet
Copy link
Member

jbenet commented Sep 17, 2016

Rest LGTM

@Kubuxu
Copy link
Member

Kubuxu commented Oct 20, 2016

I would be for making csv registry of transports and then assigning them and keeping parsing in packages with the transports. Which will be possible with #42

@keks
Copy link
Contributor Author

keks commented Oct 21, 2016

I didn't get your plan from that one sentence but I also don't get what this has to do with this PR. I mean this was laying around for a month now (idk why it wasn't merged).
I say merge it and maybe do #42 and then make this one use the new way of doing it just like all the others.

@keks
Copy link
Contributor Author

keks commented Nov 4, 2016

Is there a chance of this being merged? Is there something I can do to make it happen? paging @jbenet @whyrusleeping

@Kubuxu
Copy link
Member

Kubuxu commented Nov 7, 2016

@keks as it already conflicts with codec.go file I will pick this up and add it when #42 gets merged. Does it seems good to you?

@Kubuxu
Copy link
Member

Kubuxu commented Nov 7, 2016

Or when #42 is merged the parser can be part of the shs transport itself.

@ghost
Copy link

ghost commented Jan 21, 2017

The protocol number should be added to protocols.csv in multiformats/multiaddr before merging.

Stebalien added a commit that referenced this pull request May 20, 2020
Make PacketConn more idiomatic and direct
Stebalien added a commit that referenced this pull request May 20, 2020
marten-seemann pushed a commit to marten-seemann/go-multiaddr that referenced this pull request Feb 25, 2021
…github.com/onsi/ginkgo-1.10.3

Bump github.com/onsi/ginkgo from 1.8.0 to 1.10.3
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants