4 ms·

Anyone know why they used UTF-16 for the message type, instead of UTF-8? Also, I'm skeptical that two peers can exchange keys without a third party, without be

Anyone know why they used UTF-16 for the message type, instead of UTF-8? Also, I'm skeptical that two peers can exchange keys without a third party, without being susceptible to man-in-the-middle attacks. But maybe the paper linked in the article proves that it's possible? https://dominictarr.github.io/secret-handshake-paper/shs.pdf https://dominictarr.github.io/secret-handshake-paper/shs.pdf When I was playing with p2p 20 years ago, I found that NAT traversal was far harder than the messaging protocol (I just copied a few commands from IRC at the time). So hard in fact, that I failed to solve it after 2 years of effort. I realized later that NAT is part of a cluster of problems with networking, the main one being that TCP should have been a layer above UDP (not beside it) and that connectedness was never really a good concept (it should have used identifiers like this instead of IP addresses so the stream survives changing LAN/Wi-Fi/mobile networks). Unfortunately, the article doesn't talk about UDP much other than for broadcasting peer identifiers on the LAN. So I'm not sure how much use this would have in the real world for stuff like game networking, much less state transfer with something like a software transactional memory (STM). I wonder if anyone's made an STM that runs on a readonly transaction log like this, kind of like CouchDB, RethinkDB or Firebase maybe? But I digress. And I might have used the empty string "" to represent a null hash.. wait I misread that, they use actual null to represent the null pointer in the linked list of message hash addresses, which is great! Could this be used to build a web of trust? Or is it meant to be more transient, like maybe people broadcast on throwaway identities? Could we drop PGP into this? Maybe this is more like an RSS feed than something realtime like WebRTC? Other than that, this seems like a pretty decent protocol, these are just some thoughts/concerns that stood out for me.

cel 5y ago
> Anyone know why they used UTF-16 for the message type, instead of UTF-8? It is an artefact of the original implementation, which was not discovered until the protocol was already in wide use and being independently implemented [1]. > Also, I'm skeptical that two peers can exchange keys without a third party, without being susceptible to man-in-the-middle attacks. But maybe the paper linked in the article proves that it's possible? SSB uses the Secret Handshake (SHS) protocol in that paper (with some errata [2]). SHS is a authenticated key exchange (key agreement) protocol [3]. The two peers authenticate eachother to their respective public key, and establish a shared secret that is used to bulk-encrypt the rest of the session/connection. With SHS, the client (the peer that initiates the connection) must know the server's public key ahead of time. Both parties must know and previously agree on an additional network capability key (that is usually hard-coded to a specific value in the SSB implementations). It should be immune to MitM if the party's private keys are kept secret. There are ephemeral keypairs involved, so if a later compromise occurs of the long-term (identity) private keys, that should not reveal previous/existing sessions. SHS has been verified using Tamarin [4]. > I wonder if anyone's made an STM that runs on a readonly transaction log like this, kind of like CouchDB, RethinkDB or Firebase maybe? I'm not familiar with STM as such, but I am familiar with CouchDB. There are various ways of mutable data structures on SSB. Typically messages are indexed, in general ways (e.g. message type, author, backlinks) and/or application-specific ways. Applications query the indexes to construct some result. Graph processing is often done to handle concurrent operations by different feeds (i.e. using CRDTs). Here is a document describing threads, a common data structure on SSB: https://hackmd.io/GQ8aTw6STpuSFu6oH5Z63w https://hackmd.io/GQ8aTw6STpuSFu6oH5Z63w > Could this be used to build a web of trust? Or is it meant to be more transient, like maybe people broadcast on throwaway identities? Could we drop PGP into this? Yes, the main SSB network constitutes a web of trust. People do create throwaway identities though, just trying it out and then not returning. But some persist, and people develop and express relationships. Some people share other public keys for PGP, OMEMO, Briar, RetroShare, Dat/Hyper, etc. PGP-signed messages have been published occasionally. Creating a temporary identity is not recommended for broadcasting, because it will not have much reach: message distribution and visibility depends on the social graph. > Maybe this is more like an RSS feed than something realtime like WebRTC? Yes. A SSB feed is identified by its public key, and contains an append-only list of messages. Each message is identified by its content hash. However, the RPC protocol used for SSB could be extended to support ephemeral content. WebRTC DataChannels could be used for gossip connections. But there is still the problem of needing to exchange message to establish the WebRTC connection. Historically SSB has addressed P2P network architecture using Pubs [5], more recently with Rooms [6]. [1] https://news.ycombinator.com/item?id=29675263 https://news.ycombinator.com/item?id=29675263 [2] https://github.com/auditdrivencrypto/secret-handshake/issues/7 https://github.com/auditdrivencrypto/secret-handshake/issues... [3] https://en.wikipedia.org/wiki/Authenticated_Key_Exchange https://en.wikipedia.org/wiki/Authenticated_Key_Exchange [4] https://github.com/keks/tamarin-shs https://github.com/keks/tamarin-shs [5] https://ssbc.github.io/scuttlebutt-protocol-guide/#pubs https://ssbc.github.io/scuttlebutt-protocol-guide/#pubs [6] https://ssb-ngi-pointer.github.io/rooms2/ https://ssb-ngi-pointer.github.io/rooms2/

cel 5y ago

> Anyone know why they used UTF-16 for the message type, instead of UTF-8? It is an artefact of the original implementation, which was not discovered until the protocol was already in wide use and being independently implemented [1]. > Also, I'm skeptical that two peers can exchange keys without a third party, without being susceptible to man-in-the-middle attacks. But maybe the paper linked in the article proves that it's possible? SSB uses the Secret Handshake (SHS) protocol in that paper (with some errata [2]). SHS is a authenticated key exchange (key agreement) protocol [3]. The two peers authenticate eachother to their respective public key, and establish a shared secret that is used to bulk-encrypt the rest of the session/connection. With SHS, the client (the peer that initiates the connection) must know the server's public key ahead of time. Both parties must know and previously agree on an additional network capability key (that is usually hard-coded to a specific value in the SSB implementations). It should be immune to MitM if the party's private keys are kept secret. There are ephemeral keypairs involved, so if a later compromise occurs of the long-term (identity) private keys, that should not reveal previous/existing sessions. SHS has been verified using Tamarin [4]. > I wonder if anyone's made an STM that runs on a readonly transaction log like this, kind of like CouchDB, RethinkDB or Firebase maybe? I'm not familiar with STM as such, but I am familiar with CouchDB. There are various ways of mutable data structures on SSB. Typically messages are indexed, in general ways (e.g. message type, author, backlinks) and/or application-specific ways. Applications query the indexes to construct some result. Graph processing is often done to handle concurrent operations by different feeds (i.e. using CRDTs). Here is a document describing threads, a common data structure on SSB: https://hackmd.io/GQ8aTw6STpuSFu6oH5Z63w https://hackmd.io/GQ8aTw6STpuSFu6oH5Z63w > Could this be used to build a web of trust? Or is it meant to be more transient, like maybe people broadcast on throwaway identities? Could we drop PGP into this? Yes, the main SSB network constitutes a web of trust. People do create throwaway identities though, just trying it out and then not returning. But some persist, and people develop and express relationships. Some people share other public keys for PGP, OMEMO, Briar, RetroShare, Dat/Hyper, etc. PGP-signed messages have been published occasionally. Creating a temporary identity is not recommended for broadcasting, because it will not have much reach: message distribution and visibility depends on the social graph. > Maybe this is more like an RSS feed than something realtime like WebRTC? Yes. A SSB feed is identified by its public key, and contains an append-only list of messages. Each message is identified by its content hash. However, the RPC protocol used for SSB could be extended to support ephemeral content. WebRTC DataChannels could be used for gossip connections. But there is still the problem of needing to exchange message to establish the WebRTC connection. Historically SSB has addressed P2P network architecture using Pubs [5], more recently with Rooms [6]. [1] https://news.ycombinator.com/item?id=29675263 https://news.ycombinator.com/item?id=29675263 [2] https://github.com/auditdrivencrypto/secret-handshake/issues/7 https://github.com/auditdrivencrypto/secret-handshake/issues... [3] https://en.wikipedia.org/wiki/Authenticated_Key_Exchange https://en.wikipedia.org/wiki/Authenticated_Key_Exchange [4] https://github.com/keks/tamarin-shs https://github.com/keks/tamarin-shs [5] https://ssbc.github.io/scuttlebutt-protocol-guide/#pubs https://ssbc.github.io/scuttlebutt-protocol-guide/#pubs [6] https://ssb-ngi-pointer.github.io/rooms2/ https://ssb-ngi-pointer.github.io/rooms2/