5 ms·

Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed?

by gue5t 11y ago

newman314 11y ago
Agreed. As I mentioned in a previous thread, my idealized program is Signal+Ricochet.im+Burner-like resettable identity endpoints across desktop and mobile.
Strom 11y ago
Maybe because an excellent centralized encrypted chat doesn't exist yet. All options, including Signal, have lots of problems. Some chat apps are great, but really questionable security. Other apps have seemingly great security, but really questionable chat experience. After this duo problem of chat+encryption has been done well, we can start looking into adding additional problems like centralization.
lewisl9029 11y ago
As much as I agree with your overall sentiment, the sad truth is that centralized architectures enable many of the UX affordances that users take for granted today in a modern chat app, many of which are much more difficult, sometimes simply impossible, to implement in a decentralized architecture (think features like automatic contact discovery, offline messaging, etc). Without some of these affordances, a chat app has simply has no chance of gaining widespread adoption in such a competitive landscape. This is why it is very difficult to justify pouring any significant resources into building a decentralized chat app, because too few people will ever end up using it to justify the investment. For what it's worth, I am the author of a decentralized messaging app myself [1], and have spent a lot of time thinking about stuff like this, and eventually reached this unfortunate conclusion and decided to leave the project at the prototype stage. [1] http://toc.im/ http://toc.im/
- deanclatworthy 11y ago
  What kind of things are impossible?
  - lewisl9029 11y ago
    The two features I mentioned, automatic contact discovery and robust offline messaging, are examples of features that I have concluded to be impossible to build without some degree of centralization (there are probably more, but those two were the only ones I could recall off the top of my head). Though it is certainly possible that I simply haven't put enough thought into it. Toc's original goal was to be a decentralized messaging app that makes no compromises in terms of UX compared to a centralized messaging app. Toc managed to tackle decentralized cross platform sync, but to this day I still have no idea how to approach automatic contact discovery and robust offline messaging.
    - qrmn 11y ago
      Automatic contact discovery is tricky, but the beginnings of one potential solution is I think explored in agl's Pond, using pairings on BN curves?: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/ To a point, so is offline messaging. Distributed datastores in general do that kind of thing - there are old implementations over Freenet in particular, and GNUnet as well and other things I think. The robust part is harder: if the client is offline, where's the disk space coming from? Volunteers' (nodes') cache? That needs to be opaque, and so do lookups. What's to stop spammers flooding the network? (Spam, and denial-of-service in general, is a Hard problem to deal with in general even in distributed systems.) They're not among the hardest problems. Pseudonymity is a huge challenge as the latency gets lower against traffic correlation attacks, and a secure messenger is most definitely up against the kind of threat model that can and will try to pull those off in the wild. Perhaps mixing high and low-latency traffic may help, although it's going to need to be very carefully analysed how much (I believe I2P's design can do that, although I'm not sure if jrand0m ever implemented it in the router).
      - lewisl9029 11y ago
        Yes those are definitely not the hardest problems in this space. I was only referring to UX-related features in my original post (i.e. rather than the much more tricky privacy and security related ones), ones that I couldn't figure out how to actually implement in the context of a client-side web app. Impossible was probably too strong of a word to express that. Thank you for all the interesting ideas and resources though! They'll definitely come in handy when I eventually revisit this space when I have more time later on.
tptacek 11y ago
Because that's still an unsolved research problem. Rogaway mentions it, in some detail, in his recent paper: https://news.ycombinator.com/item?id=10655418 https://news.ycombinator.com/item?id=10655418
fweespeech 11y ago
> Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed? https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily https://blog.torproject.org/blog/tor-messenger-beta-chat-ove... > Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. That is essentially what happens with Signal and every other service as well. No metadata, truly anonymous communication between trusted parties is an unsolved research problem.
leni536 11y ago
What about Ring and Tox? https://tox.chat/ https://tox.chat/ https://ring.cx/ https://ring.cx/ AFAIK both offers p2p communication and discovery. I don't think that they are entirely tor compatible though, maybe if you only use the chat part.
Nutomic 11y ago
I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon! But as others have mentioned, many problems become really difficult in a decentralized application, most importantly offline messaging. [1] https://github.com/Nutomic/ensichat https://github.com/Nutomic/ensichat

Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed?

by gue5t 11y ago

Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed?

Agreed. As I mentioned in a previous thread, my idealized program is Signal+Ricochet.im+Burner-like resettable identity endpoints across desktop and mobile.

Strom 11y ago

Maybe because an excellent centralized encrypted chat doesn't exist yet. All options, including Signal, have lots of problems. Some chat apps are great, but really questionable security. Other apps have seemingly great security, but really questionable chat experience. After this duo problem of chat+encryption has been done well, we can start looking into adding additional problems like centralization.

lewisl9029 11y ago

As much as I agree with your overall sentiment, the sad truth is that centralized architectures enable many of the UX affordances that users take for granted today in a modern chat app, many of which are much more difficult, sometimes simply impossible, to implement in a decentralized architecture (think features like automatic contact discovery, offline messaging, etc). Without some of these affordances, a chat app has simply has no chance of gaining widespread adoption in such a competitive landscape. This is why it is very difficult to justify pouring any significant resources into building a decentralized chat app, because too few people will ever end up using it to justify the investment. For what it's worth, I am the author of a decentralized messaging app myself [1], and have spent a lot of time thinking about stuff like this, and eventually reached this unfortunate conclusion and decided to leave the project at the prototype stage. [1] http://toc.im/ http://toc.im/

deanclatworthy 11y ago
What kind of things are impossible?
- lewisl9029 11y ago
  The two features I mentioned, automatic contact discovery and robust offline messaging, are examples of features that I have concluded to be impossible to build without some degree of centralization (there are probably more, but those two were the only ones I could recall off the top of my head). Though it is certainly possible that I simply haven't put enough thought into it. Toc's original goal was to be a decentralized messaging app that makes no compromises in terms of UX compared to a centralized messaging app. Toc managed to tackle decentralized cross platform sync, but to this day I still have no idea how to approach automatic contact discovery and robust offline messaging.
  - qrmn 11y ago
    Automatic contact discovery is tricky, but the beginnings of one potential solution is I think explored in agl's Pond, using pairings on BN curves?: https://pond.imperialviolet.org/ https://pond.imperialviolet.org/ To a point, so is offline messaging. Distributed datastores in general do that kind of thing - there are old implementations over Freenet in particular, and GNUnet as well and other things I think. The robust part is harder: if the client is offline, where's the disk space coming from? Volunteers' (nodes') cache? That needs to be opaque, and so do lookups. What's to stop spammers flooding the network? (Spam, and denial-of-service in general, is a Hard problem to deal with in general even in distributed systems.) They're not among the hardest problems. Pseudonymity is a huge challenge as the latency gets lower against traffic correlation attacks, and a secure messenger is most definitely up against the kind of threat model that can and will try to pull those off in the wild. Perhaps mixing high and low-latency traffic may help, although it's going to need to be very carefully analysed how much (I believe I2P's design can do that, although I'm not sure if jrand0m ever implemented it in the router).
    - lewisl9029 11y ago
      Yes those are definitely not the hardest problems in this space. I was only referring to UX-related features in my original post (i.e. rather than the much more tricky privacy and security related ones), ones that I couldn't figure out how to actually implement in the context of a client-side web app. Impossible was probably too strong of a word to express that. Thank you for all the interesting ideas and resources though! They'll definitely come in handy when I eventually revisit this space when I have more time later on.

tptacek 11y ago

Because that's still an unsolved research problem. Rogaway mentions it, in some detail, in his recent paper: https://news.ycombinator.com/item?id=10655418 https://news.ycombinator.com/item?id=10655418

fweespeech 11y ago

> Why are all these encrypted chat programs (Signal, Telegram, &c.) still centralized and not TOR-style onion-routed? https://blog.torproject.org/blog/tor-messenger-beta-chat-over-tor-easily https://blog.torproject.org/blog/tor-messenger-beta-chat-ove... > Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. That is essentially what happens with Signal and every other service as well. No metadata, truly anonymous communication between trusted parties is an unsolved research problem.

leni536 11y ago

What about Ring and Tox? https://tox.chat/ https://tox.chat/ https://ring.cx/ https://ring.cx/ AFAIK both offers p2p communication and discovery. I don't think that they are entirely tor compatible though, maybe if you only use the chat part.

Nutomic 11y ago

I'm currently working on a decentralized instant messenger Ensichat [1] which does exactly that. Right now, it only works over Bluetooth, but internet support will be coming very soon! But as others have mentioned, many problems become really difficult in a decentralized application, most importantly offline messaging. [1] https://github.com/Nutomic/ensichat https://github.com/Nutomic/ensichat