Usage question for Noise with IK handshake

[dignifiedquire]

I am trying to build a transport that supports doing the Noise IK handshake with n different peers. This list of peers is manually added through a command line, and so will change over time. As far as I can tell the docs only really show the IK pattern with a single peer identity known at startup.

Would appreciate any help on how to best implement this.

[burdges]

I missread your comment as being about group key exchanges. You presumably mean n pairwise handshakes, so ignore this comment. :)

---

Why? If your transport layer is point-to-point then you should really encrypt point-to-point for authentication, etc. All "handshake" protocols like Noise and TLS 1.3 depend upon an AEAD for authentication, which only makes sense for two parties.

As a rule, encryption should operate near your transport layer because unencrypted layers/communications complicates understanding the protocol. SECIO sucks partially because due to running further up the stack.

Are you doing IP multicast or similar? If so, you need temporary IP addresses for each multicast group, right? I'd expect group coordination requires separate point-to-point links anyways, right? You could simply distribute a single symmetric key across these point-to-point links. You should encrypt each datagram packet separately with random nonces, presumably like DTLS 1.2. You'll need custom flow control too, for which I'd investigate erasure codes.

As a warning, there are higher level protocols for Byzantine agreement, etc. that make security assumptions about gossip protocols. IP multicast depends upon support from intermediate routers. I'd therefore think gossip over IP multicast needs, not only reliable multicast, but cryptographically enforced reliable multicast. I've no idea if anyone specified such a protocol, but it needs secrets between each broadcaster and each recipient. In this vein, internet routers should manage IP multicast group addresses through roughly BGP, which gives another vulnerability zoo.

Are you doing some "messager" with untrusted asynchronous delivery? As a rule, messengers should employ forward secure "ratchets", which many messengers like Telegram screw up, and groups make much harder. MLS should provide a good solution, eventually. Also [email protected] has good discussions around this topic. Afaik, all the current secure group messengers like Signal and Wire employ what Trevor Perrin calls "sender keys".

All this "messaging layer crypto" complexity stems from (a) doing encryption above the transport layer and (b) doing groups.

[tomaka]

Afaik the IK handshake isn't really fleshed out in rust-libp2p.
For context: #1423

[dignifiedquire]

@burdges thank you for the great comments, but yes I am not trying to do a group key exchange. The goal is to do a permissioned network, where all participants have a shared configuration file communicated out of band ahead of time.

[dignifiedquire]

The "dynamic update" capabilities come from the fact that this configuration does get updated from time to time when new members are added to the network.

[dignifiedquire]

As an alternative @tomaka is there any way currently to whitelist peers? I have seen the ban_peer functionality, but I would want to do the opposite, eg whitelist_peer and disallow connections to all other peers.

[tomaka]

As an alternative @tomaka is there any way currently to whitelist peers?

Not through the swarm, no.

[mxinden]

Closing here, as the discussion seems to have stalled. @dignifiedquire please re-open in case you would like to continue the conversation.