What is Secio?

[victorb]

So, after seeing both https://github.com/ipfs/go-libp2p-secio and https://github.com/libp2p/js-libp2p-secio with some discussions happening about how to make the two work together, there doesn't seem to be a description of what Secio actually is. Tried doing some googling as well, but seems to have been a thing invented together with the libp2p stuff.

Would be nice to include either a link to a description in the two repos or at least a short description about what it is in them.

[daviddias]

secio is our implementation of a crypto channel. It exists since there was none TLS 1.3(RFC, talk) like crypto channel available at the time and even today, there is none (TLS 1.3 is just a draft).

@dominictarr has written down a good description of how it works. Dominic, could you link it here?

@victorbjelkholm also cool to read -> https://dominictarr.github.io/secret-handshake-paper/shs.pdf

[dominictarr]

https://github.com/auditdrivencrypto/secure-channel/blob/master/prior-art.md#ipfss-secure-channel

also ipfs/kubo#1201

[JustinDrake]

Can I confirm that IPFS is designed in a way that secio channels are agnostic of (application-level) PeerID?

For example, assume a relay node R (e.g. one that implements the line relay protocol) that is directly connected with secio channels to two nodes A and B. If A sends a message to B through R, will B accept the message even though it comes from a secio channel with R (instead of A)?

[daviddias]

@JustinDrake secio is an end to end crypto protocol whose handshake is through asymmetric crypto and since public key is the Id (Id = hash(publicKey)). A can connect to B through any network or setup and still verify that it is talking with B and not have its messages tampered with.

[raulk]

Would it be fair to characterise SecIO as an implementation of the Integrated Encryption Scheme? Particularly it shares many similarities with the Ethereum v1 ECIES scheme used in RLPx.

• Parties are authenticated via their static pubkeys.
• Ephemeral keys are exchanged, and symmetric key is calculated via a key agreement function taking both keys into account.
• There is a common key agreement function that combines the counterparties' pub key with our priv key to generate a shared secret.
• There is a key derivation function (KDF), but in this case it stretches the derived shared secret to compute two keys, one for sending messages, one for receiving. The same keys are derived on the other end, but they are flipped.
• Packets are MAC-authenticated but these are not sliding MACs, unlike in Ethereum. RLPx is a TCP protocol, but SecIO can wrap UDP transports which means that datagram order is not guaranteed and using a sliding MAC could be problematic.

Is this a fair assessment? Helps me place SecIO within a domain that I already know.

[Stebalien]

It was modeled after TLS but intentionally dropped the CA/certificate integration. Juan wanted to use TLS but apparently the go package made this difficult (at the time) without using the CA system (although it may have been possible with some nasty hacks).

[bigs]

would be great to get a contribution for this :)