libp2p+noise: Win a Data Terra Nemo’19 conference ticket!
This is a duplicate of https://github.com/libp2p/go-libp2p/issues/631 for communication purposes; refer to that issue as it’s the canonical source.
Submissions open until 14th May 2019 23:59:59 UTC. Winner announced on 15th May 2019.
Hey hackers!
We are looking to implement a proof of concept for a Noise-based handshake in go-libp2p
, and we know you’re eager to help!
And there is a prize! To reward the winning submission, Protocol Labs is giving away a ticket to Data Terra Nemo 2019.
Data Terra Nemo is a technical conference for hackers and computer scientists focused on distributed and decentralized systems, taking place in Berlin next week (May 17-18th). It’s an excellent occasion to learn from – and interact with – top-notch thought leaders and hackers in the space. Just look at the speaker roster!
The conference has been sold out for weeks, and there’s a sizable waiting list, so we trust you’ll appreciate how truly exceptional this opportunity is to attend. The ticket is valued at 240€.
Background
We are looking to adopt the IX
Noise handshake. We are inspired by Wireguard and Matrix, both of whom use the IK
handshake.
IK
and IX
diverge in the prior knowledge that the initiator has of the responder’s static public key:
- In
IK
, the initiator HAS this knowledge and can preserve the privacy of its own public key by encrypting it to the responder’s static public key. - In
IX
, the initiator LACKS this knowledge, but can otherwise authenticate the peer upon receiving their public key.
In a peer-to-peer setting, public keys are exchanged readily, and peers need to prove their identity frequently, so attempts to preserve the initiator’s identity are redundant. Such configurations are more relevant in hub-and-spoke-like models, or client-server settings.
More information in this post by Latacora. See also the IX handshake in the Noise Explorer.
Note: in libp2p, the peer ID is derived by hashing the public key struct, and the initiator always knows the peer ID of the responder when establishing a connection.
Integration with libp2p
When libp2p peers connect, they negotiate the protocol for establishing a secure, authenticated channel. You don’t need to know the details of this process.
If both parties support Noise IX
, you can safely assume that libp2p will select the module you’ll be building to establish the crypto channel.
We currently support two protocols:
- SecIO, implemented in libp2p/go-libp2p-secio, identified by protocol ID
/secio/1.0.0
. - TLS 1.3, implemented in libp2p/go-libp2p-tls, identified by protocol ID
/tls/1.0.0
.
The Noise IX
handshake will be the third member of that list. You can use those two as reference.
The challenge
Target: Implement and integrate the Noise IX handshake in go-libp2p!
We’re aware that this might be bit rushed, so don’t feel your implementation should be perfect, robust or complete. It does make for a neat weekend project, though!
Our main goal is to get a decent headstart, and to get you buzzed about contributing to libp2p and shaping the future of peer-to-peer networking in general! We’ll definitely use this to scout for talent too
If you do manage to reach feature completeness and high robustness via tests of all kinds, that’s great! For all reasonable submissions that don’t win, there’ll be something in store for you, don’t worry
Technical details
- Let’s assign it the
/noise/ix/1.0.0
protocol ID. - You can use the Go handshake pattern code generator from Noise Explorer, but you’ll need to integrate it with our keys.
- See
go-libp2p-crypto
andgo-libp2p-peer
.
- See
- Your solution will need to conform to the
connsec.Transport
interface, and it’ll need to produce aconnsec.Conn
connection, so that it can interoperate withgo-libp2p
.- Refer to the SecIO and TLS 1.3 implementations for guidance.
- If you need to build a mental model of go-libp2p, use the emerging go-libp2p-core repository (consolidate-skeleton branch). We are consolidating all abstractions there from a number of repos.
- Include unit tests.
- Include integration tests where you instantiate a libp2p
Host
via the entrypoint constructorlibp2p.New(...)
, injecting your security channel as via theSecurity()
option.
Submissions
Submissions open until 14th May 2019 23:59:59 UTC. Winner announced on 15th May 2019.
Here’s the process if you intend to participate:
- Email
[my github username without the k]@protocol.ai
now, and tell us who you are and how you plan to approach this! - If you have any questions, post them on this issue, or send them privately if you’d like to keep your participation anonymous while the contest is active.
- Create a repo under your GitHub account, and do your hacking there. If you’re concerned about competition, you can make the repo private and add me as a viewer. (Thanks Github for making this free!).
- Before the contest closes (May 14th 23:59:59 UTC), submit a PR to the libp2p/go-libp2p-noise repo, linking to this issue.
- If you need further guidance, or something is unclear, email
[my github username without the k]@protocol.ai
. - We’ll judge aspects like completeness, readability, test coverage, thoughtfulness, etc.
Protocol Labs employees and contributors are allowed to participate, but WILL NOT be considered for the prize. In the case a Protocol Labs submission wins, the reward will go to the next best non-PL submission.