(reposting to the list, I'll learn one of these days..)

On Fri, Apr 6, 2018 at 7:59 PM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
[..]

Let me know if you have any more questions or ways in which I can help
you guys out with the p2p protocol.


Hey, thanks for the reply. Another issue came up while I've been looking into this:

At present, one has to manually add specific peers in order for WG to authenticate them. I was wondering what the options are for dynamic authentication, of peer keys that one doesn't know beforehand. The typical example would be a PAKE but for us it would be an alternative zero-knowledge proof that the initiator's key belongs to some allowed-set of peers wrt the responder's key, as defined by the rest of the protocol (I'm being vague because the details are TBD, actually).

It would be nice to keep WG's current property of being able to authenticate a client on the first packet without requiring further communication. To reduce the DoS-potential of having to verify a complex zk proof, we can probably also include a proof-of-work linked to a recent global shared source of randomness (we have that in our protocol). So one way would be for WG to hook into a custom function that reads a custom certificate from the first incoming packet and say whether it passes the test.

Alternatively we can listen on another socket, perform the custom check on incoming packets here, and then forward passing packets with our custom portion stripped out onto the local WG socket. Hopefully this would "just work" if the "from" address on the UDP packet is correct. However, initiating these would be tricky, we'd have to intercept the WG initial outgoing packet and rewrite it.

Other suggestions would be much appreciated.

X