Ephemeral Key Not Found in Noise Protocol Handshake Process

[normanade]

As I understand, Noise protocol in XX pattern takes three steps of information exchanging(source):

Initiator   -> e          Responder
Initiator   <- e,ee,s,es  Responder
Initiator   -> s,se       Responder

However in libp2p, upon a noise xx connection upgrade request, we use rt15_initiator/responder(code link), which performs:

initiator --{}--> responder
initiator <-{id}- responder
initiator -{id}-> responder

How does an empty message send out the ephemeral key? And by {id}, I notice that only public key(in protobuf format) and signature are sent between initiator and responder.
Where does the exchange of ephemeral key take place? Shouldn't there be some DH calculation between the static key and the ephemeral key?

[normanade]

Using Wireshark I noticed three tcp packages after responder agreed with initiator's proposal of noise upgrade.

Initiator -> 32 bytes   Responder
Initiator <- 200 bytes   Responder
Initiator -> 168 bytes   Responder

However can't make sense of these packages. Data after these three packages are encrypted.

[mxinden]

Hi @normanade,

Thanks for raising this question.

The call to send_empty does not send an overall empty Noise message, but instead the first Noise message of the XX handshake with an empty additional user payload.

rust-libp2p/transports/noise/src/io/handshake.rs

Line 209 in 2c739e9

send_empty(&mut state).await?;

write_empty will result in a call to HandshakeState::write_message which will write both the Noise handshake payload and the (here empty) user payload.

Let me know in case the above makes sense.

[normanade]

Thanks for the answer, that's the case indeed.

[normanade]

After reading the noise spec, I realised that this send_empty&send_message api set is implemented by crate snow, which does the ephemeral key exchanging behind the scene.
For further explanation:

Info sent by snow
Initiator -> 32 bytes   Responder      the initiator sent its ephemeral key(e, 32 bytes), in cleartext
Initiator <- 200 bytes   Responder      the responder sent its ephemeral key(e, 32 bytes), in cleartext
Initiator -> 168 bytes   Responder

Libp2p users can neither change the ephemeral key, nor print them. The only way of acknowledging the key is using the network interception softwares.

Difference between send_empty and send_message is the payload stuffed into the noise handshake TCP package. The responder's send_message call sets the protobuf struct(104 bytes) as the es payload, while the initiator send another protobuf struct as se.