[Contest] libp2p+noise: Win a Data Terra Nemo’19 conference ticket!

[raulk]

libp2p+noise: Win a Data Terra Nemo’19 conference ticket!

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 conceal the initiator’s identity from observers 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 and go-libp2p-peer.
• Your solution will need to conform to the connsec.Transport interface, and it’ll need to produce a connsec.Conn connection, so that it can interoperate with go-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 constructor libp2p.New(...), injecting your security channel as via the Security() 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:

1. Email [my github username without the k]@protocol.ai now, and tell us who you are and how you plan to approach this!
2. 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.
3. 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!).
4. Before the contest closes (May 14th 23:59:59 UTC), submit a PR to the libp2p/go-libp2p-noise repo, linking to this issue.
5. If you need further guidance, or something is unclear, email [my github username without the k]@protocol.ai.
6. 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.

[raulk]

Unfortunately we didn't receive any submissions in time, but the spec and requirements are still valid for anyone who wants to help out. In fact, I'd like to bounty this out via Gitcoin or similar.

[emilbayes]

@raulk Have you seen https://noiseexplorer.com/patterns/IX/ ?

[raulk]

@emilbayes yeah! the contest actually recommended using the Go code from there as a starting point.

[emilbayes]

@raulk Ah sorry, I see

[raulk]

@emilbayes what do you think about the choice of IX? My rationale is that in a p2p setting, nodes exchange public keys readily, so pushing the initiator's pubkey allows us to save a roundtrip vs. XX without compromising security properties in practice.