Skip to content
This repository has been archived by the owner on May 26, 2022. It is now read-only.

Initial go-libp2p-noise implementation #2

Merged
merged 49 commits into from Dec 5, 2019

Conversation

noot
Copy link
Contributor

@noot noot commented Aug 24, 2019

This PR includes an initial implementation of the libp2p noise spec

  • if noise pipes are enabled, first try IK. if that fails, pipe messages to XXfallback
  • if noise pipes are disabled, do XX

The IK/XX noise files are mostly auto-generated code from the noise explorer + some modifications and helpers.

noot and others added 30 commits August 23, 2019 17:30
implemented IK handshake
modified IK generated noise file to export needed funcs + made helpers
added 2 byte length prefix to messages
separated IK and XX related funcs into different files
added Noise related fields to Transport, allows for saving of static noise key in Transport
pipe from XX->IK works, IK->XXfallback in progress
return mb, nil
}

func validatePublicKey(k []byte) bool {
Copy link

Choose a reason for hiding this comment

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

The lower order point blacklist is unnecessary in noise because the state accumulator ensures that view divergence caused by injecting lower order points via man in the middle attack causes the state hashes to diverge and handshake to fail.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This file (as well as IK.noise.go) is autogenerated from the noise explorer, could you open an issue there? https://github.com/SymbolicSoft/noiseexplorer

Copy link

Choose a reason for hiding this comment

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

I'm not going to interact with noiseexplorer explorer because of who the authors are.

Also the code, it generates is pretty unidiomatic and has issues like this.

I'd be interested in providing a more compatible and higher quality implementation of the underlying noise handshakes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah we would also be interested in that, how do you propose we make that happen?

Choose a reason for hiding this comment

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

@zmanian Any update on a proposed path of action?

xx/XX.noise.go Outdated
var ss symmetricstate
var e Keypair
var re [32]byte
name := []byte("Noise_XX_25519_ChaChaPoly_BLAKE2s")
Copy link
Member

Choose a reason for hiding this comment

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

Isn't this suppose to be Noise_XX_25519_ChaChaPoly_SHA256?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yeah definitely, this was autogenerated from the noise explorer which only supported BLAKE2s, I had to manually change the hashing algo to SHA256 but I looks like I didn't change the name. I'll change it now

xx/XX.noise.go Outdated
var ss symmetricstate
var e Keypair
var re [32]byte
name := []byte("Noise_XX_25519_ChaChaPoly_BLAKE2s")
Copy link
Member

Choose a reason for hiding this comment

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

and here also

Copy link
Contributor Author

Choose a reason for hiding this comment

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

same as above. the code does use SHA256, just gotta update the string

Copy link
Contributor

@yusefnapora yusefnapora left a comment

Choose a reason for hiding this comment

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

Hey @noot and other ChainSafe folks 👋

Thanks for making this implementation happen! I'm getting ready to pull this in to the libp2p org and update it to match a few changes we've made to the spec since it was written.

I found a bug in the Noise pipes implementation as I was reviewing that was causing it to always use XX, but I've got a fix and will make a PR after we get this in. I can tag you on it if you're interested.

Cheers & thanks again 😄

done := make(chan struct{})
go func() {
defer close(done)
respConn, respErr = respTransport.SecureOutbound(context.TODO(), resp, initTransport.LocalID)
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems backwards to me. Shouldn't the initiator be the one securing the outbound connection to the responder?

@yusefnapora
Copy link
Contributor

Just wanted to write up some things that I found while reviewing today that I'd like to address after we merge in. I'll open issues for these as well so we don't lose track.

  • the TestHandshakeIK and TestHandshakeXXfallback tests check that a handshake completes successfully, but they don't check which handshake pattern was used.
  • the conditional logic around whether to use the IK handshake is a bit off, so it ends up always using XX. this wasn't noticed because of the issue with the tests
  • the cache for static noise keys is a go map that's shared across all sessions. Since multiple sessions can be in flight concurrently, this isn't safe, since go maps aren't threadsafe
  • the ciphertexts sent after the handshake completes are prefixed with uint16's but the length of the ciphertext isn't checked to make sure it fits (is less than 65,535 bytes). we should fragment large ciphertexts into multiple length-prefixed messages

@yusefnapora yusefnapora marked this pull request as ready for review December 5, 2019 14:49
@yusefnapora yusefnapora merged commit 038ccd8 into libp2p:master Dec 5, 2019
@noot noot deleted the begin-noise branch December 13, 2019 20:28
@noot
Copy link
Contributor Author

noot commented Dec 13, 2019

@yusefnapora Hey, just saw this now! Thanks so much for the merge + feedback. I would definitely be interested in keeping up with further updates and issues, going to go through the changes now :)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants