Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Noise handshake is inefficient #433

Open
Menduist opened this issue Jul 27, 2022 · 1 comment
Open

Noise handshake is inefficient #433

Menduist opened this issue Jul 27, 2022 · 1 comment

Comments

@Menduist
Copy link
Contributor

Menduist commented Jul 27, 2022

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 #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
Copy link
Member

mxinden commented Jul 29, 2022

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Triage
Development

No branches or pull requests

2 participants