search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

Noise handshake is inefficient #433

Open Menduist opened 2 years ago

Menduist commented 2 years ago

Currently, we use a XX handshake as part of the Noise spec. X stands for: Static key for sender Xmitted ("transmitted") to recipient

So XX is used when we want A & B to chat with each other using an ephemeral key, while proving that they hold a static key. This seem perfect in our scenario (the static key being our PeerId), except that this private key has to be Diffie–Hellman'ed, which is not possible with every form of PeerIds.

What we do instead is that we sign our ephemeral key using our PeerId key. But then, what's the point of the noise static key? Currently, we just generate a random one, and it serves a similar purpose to the ephemeral key.

Here is the current libp2p scheme, in noise terms:

-> e
<- e, ee, s, es, (PeerId public key, s signed by PeerId key)
-> s, se, (PeerId public key, s signed by PeerId key)

What we propose here is to lighten this scheme, by basing it on NN instead of XX:

-> e
<- e, ee, (PeerId public key, secret derived from ee signed by PeerId key)
-> (PeerId public key, secret derived from ee signed by PeerId key)

We should send only the signature of the secret derived from ee, not the secret itself!

This gets rid of s, es, and also fixes https://github.com/libp2p/specs/issues/355, since the signature now depends on data provided by both peers.

Unfortunately, this doesn't save much bandwidth, computation or RTTs, but still an improvement, and most importantly, fixes 355.

cc @s1fr0

mxinden commented 2 years ago

This makes sense to me. Fixing #355 would indeed be good. Thanks for writing it out @Menduist!

I won't be able to drive such effort, though could support someone else who would like to tackle it. If I am not mistaken, this could be rolled out without disruption using a new protocol identifier (e.g. /noise-nn).