You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
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:
What we propose here is to lighten this scheme, by basing it on
NN
instead ofXX
: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
The text was updated successfully, but these errors were encountered: