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:
Diffie–Hellman key exchange[nb 1] is a mathematical method of securely exchanging cryptographic keys over a public channel and was one of the first public-key protocols as conceived by Ralph Merkle and named after Whitfield Diffie and Martin Hellman. DH is one of the earliest practical examples of public key exchange implemented within the field of cryptography. Published in 1976 by Diffie and Hellman, this is the earliest publicly known work that proposed the idea of a private key and a co Tradi...
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 !