Transport encryption

I can see from go implementation a daemon flag:

cmdkit.BoolOption(unencryptTransportKwd, "Disable transport encryption (for debugging protocols)"),

What precisely does it mean “transport encryption”? Are all the bitswap exchange, swarm blocks encrypted/decrypted when sent/received?

I was following the code and saw the secure_conn but couldn’t find the place of encryption. Digging more, I only found some handshakes and identity verification based on the Peer ID and Pub key.

Are the data sent over the wire visible to everyone or? As far I see a TCP connection is being used right?

The following doc is also not very useful: https://github.com/ipfs/go-ipfs/blob/master/docs/transports.md

Thx

All connections are encrypted and authenticated using a something we call secio. We’re working on switching to TLS but that’s a work in progress.

Hey @stebalien i went through the secio library as well as all the links over here: https://github.com/libp2p/go-libp2p-secio/issues/7 but I can’t find the place in code where IPFS is actually performing data encryption.

As far I see the Secio library is handling authentication of the peers but the connection itself is still TCP without encrypting the blocks.

Secio crates both an ETM (encrypt then mac) reader/writer with NewETMWriter/NewETMReader (found in rw.go) and then reads/writes through them (take a look at the end of the handshake in protocol.go.

ahhh I see! All right. Thx a lot @stebalien.

If I should sum up, all IPFS swarm communication is encrypted in the following way:

  • a handshake is done to verify identity between peers and agree on curve type, hash type etc
  • the protobuf messages are encrypted using AES (cipher XOR operation), for performance and large payloads I guess
  • (not sure about this one) the secret cipher key used for encryption is generated using elastic curve algo based on recipient pub key

How is the secret cipher key shared with recipient?

I couldn’t get my head around this part:

// generate two sets of keys (stretching)
k1, k2 := ci.KeyStretcher(s.local.cipherT, s.local.hashT, s.sharedSecret)

I would expect the secret cipher key to be encrypted using recipient pub key and send to him.

1 Like

I would expect the secret cipher key to be encrypted using recipient pub key and send to him.

We use Diffie-Hellman key exchange:

This allows both endpoints to independently generate the same shared secret without ever sending it over the network.

the secret cipher key used for encryption is generated using elastic curve algo based on recipient pub key

The secret key is generated using the above key exchange.

1 Like

Hm that’s neat. Thx for your support @stebalien!