Echo protocol implementation into RicoChet-Refresh

[Sammysupport]

Hello,

I like the simplicity of the RicoChet GUI very much and thought a bit about it. If not a code base change like Freenet to Hyphanet is considered, the Messenger needs to develop a bit - without loosing the GUI simplicity I like so much.

One suggestion could be to chat also over the Echo-protocol (e.g. using a Spot-On Server or SmokeStack Server):

• https://github.com/textbrowser/spot-on
• https://github.com/textbrowser/smokestack

This adds strong encryption and anonymity to anonymity.

Three implementations as pathes would be possible within the Tor Network respective this RicoChet Tor-Messenger:

a) R2-Alice - Echo - Tor - Tor - Echo - R2-Bob (Echo Tor-tunneled) b) R2-Alice - Tor - Internet - Echo-Server - Internet - Tor - R2-Bob (Tor-proxied Chat-Server, which only accepts encrypted packets) c) R2-Alice - Echo-Server - R2-Bob (direct connection to Echo-Server with only encypted packets)

I think the last one could be a start and is immediately the second one. The first path a) is to send echo-packets over R2-Chat, which needs a kind of binding or api.

The benefits are:

• use given code to enhance the messenger
• fast implementation by many copy/paste steps
• have reliability in messaging
• having multi-encryption
• making the network stronger and more flexible
• having messaging over Tor introduced
• having the community involved in building up Messaging over Tor.

This is for sure some work or need of funding, and as c+ and Qt / QML is given, its seems just to be a copy of the given source code of the strong encrypting protocol,

It is to be assumed, that hiden server to hidden server is not so fast and drops packets, in case you have experienced this, like Briar. Additional Echo-Servers - reached by Tor or not - can integrate messaging in the above suggested way in a long term disussion, so probably this request could be left open for further discussions.

Kind regards Sam

[morganava]

Regardless of whether or no Echo + tor is a good idea, I don't think the additional complexity of marrying Ricochet-Refresh's onion-service first protocol with other non-tor first protocols is a good idea (see the myriad unexpected problems marrying onion-services, http, and dns). In general, let's take this existing thing but do it over tor leads to unexpected security+anonymity complications in my experience.

Now if there are specific good ideas around what the v4 Ricochet-Refresh chat protocol should include, I'm all ears! Once the remaining documentation/security audit work for Gosling has completed I will be transitioning over to Ricochet-Refresh v4 protocol+ux design and prototyping which will be a complete departure from our current legacy codebase's problems and mistakes so we can make all kinds of new and interesting problems and mistakes (mostly kidding lol).

[Sammysupport]

I like our humor, you neither adore complexity nor complications nor completeness, which is good :-) For one topical issue one correction, be sure that Echo is Tor ready, it needs only in the middle a tor-hidden and tor-addressed Echo-server, like any SecureDrop in the Web. Do you propose, that SecureDrops are insecure and have interesting problems and mistakes? No. Let's have a vision, not only a next version. And for sure a start instead of a complete departure :-) Hybridity is nice and was as well, when ed2k met gnutella chunks? today it is just a tunnel or existing messaging code.

[morganava]

It's also important to point out that user anonymity, security and privacy is the number one no-compromise feature of Ricochet-Refresh, so pretty much any scheme that isn't User -> Tor -> ... Tor -> User is going to be a no-go. Other schemes belong in other tools with weaker guarantees.

[Sammysupport]

Just two of probably 80 SecureDrops are hidden servers and a server within the internet, not onion-hidden. But I understand your blind spot very well. So we focus on A) and B) of above. This is easy to create as the app is just set to localhost. Done for the number one guarantee?!

PS: Can you tell me, why the Tor-Browser's Update Button is not contacting a hidden onion server but one directly in the Internet?

[morganava]

Just two of probably 80 SecureDrops are hidden servers and not a server within the internet. But I understand your blind spot very well. So we focus on A) and B) of above.

Many SecureDrop instances run onion services (see about:rulesets in Tor Browser for link to the mappings from *.securedrop.tor.onion domains to to onion service domains.

The main properties onion services offer over clearnet (for websites) are anonymity and censorship resilience for the server. They also guarantee as a side-effect the anonymity of their users since you cannot access onion services without tor.

SecureDrop instances are typically run by professional journalist organisations, most of which don't arguably need these properties (whether that is true or not varies from locale to locale and ones level of paranoia of course).

Side note and going back a post yeah, I would argue that SecureDrop being a web-app is/was a historical mistake in some ways. Firefox (which Tor Browser is based off of) is a very large piece of software and has a large attack surface (which is one reason why SecureDrop recommends, maybe requires that JS be disabled when visiting an instance). The counter-argument of course is that a whistleblower becomes more suspicious to authorities if they were to have a hypothetical SecureDrop whistle-blowing application installed instead of Tor Browser which is just a web browser. I'm not sure authoritarians really care about this distinction but that's the argument.

This is easy to create as the app is just set to localhost. Done for the number one guarantee.

This is incredibly not true in the general case. For instance if the protocol transmits local network information, local user information, etc. See the entire history of Tor Browser as a counter-point here. Simply running your existing protocol over tor is not good enough.

PS: Can you tell me, why the Tor-Browser's Update Button is not contacting a hidden onion server but one directly in the Internet?

Mostly a lack of a pressing need to and the realities of prioritizing required work over nice-to-haves.

Tor Browser fetches its updates (and all network traffic) over tor, so user anonymity is preserved. Updates are signed with our private keys and the sigs are verified before applying them. The downsides of using an onion-service would be increased load on the tor network and lower update download speeds.

So without a pressing need to do it and some downside, we haven't :woman_shrugging: I think using the torproject's onion service as a fall-back is something we may do in the next major release cycle (14.5) but don't quote me on that :smile:

[Sammysupport]

many thanks!

• don't quote me, I think all the traffic to the tor website is monitored, so also all Torbrowser clients pressing the update button.
• Simply running the existing protocol of choice over tor is secure enough, as this protocol has no IP-Adresses and user-information: That's why it is requested here. It is "beyond cryptographic routing", don't search for it, in case you do not want to snap a bucket of flowers. :bouquet: :bride_with_veil:

[morganava]

• don't quote me, I think all the traffic to the tor website is monitored, so also all Torbrowser clients pressing the update button.

Well no, presuming torproject.org traffic is passively surveilled (you know, like the rest of the internet) such an adversary would see tor exit relays downloading something from torproject.org, not the requesting tor client.

[Sammysupport]

thanks, yes, agreed.

Means for me also that a server added to tor for chat (client - tor- server - tor - client) just for encrypted packets is also secure as this server gets only encrypted packets and is from both sides behind tor and has not metadata about users and cannot surveil.

If that architecture is indeed faster than hidden to hidden server (client, hidden - tor - tor - client, hidden), then to the other architecture of pathes can be switched. I think also Cwtch has added some server features for group-chat, even if onionbased, then the architecture is still like onionshare with chat, where only one hidden server operated in one of either clients (Torbrowser - Tor- Hidden Server Chatroom).

Do you agree, that an encrypted server (as requested here an echo server) in the middle is like a hop of Tor (as it is just: Tor - encrypted to Middel, enrypted back to - Tor). (In regard of your last sentence).

The server in the middle also brings offline messaging.

If latency and reliability is also positve, I see no obstacles in tech, and strategic aspects could be accordingly.

Well, hybrid #190 or codebasechange #192 (here with addtional capability to be run without localhost), require both a tor-reachable server, but both variants ( #192 with Gosling for sure per default also without, but that is the same as is currently for Rico Refreshed) ensure that all clients are behind Tor and are always encrypted. There should be no security risk in any path creation.

Is there a possibility to compare both architectures respective pathes with tor in speed and reliability of messages with a small group, e.g. blueprint can get together? as in science interested people we all appreciate evaluations?

[morganava]

Group chat is definitely easier with a centralised server, but I want to explore purely peer-to-peer group chat before resorting to a centralised solution.

[Sammysupport]

Echo can run serverless: Echo Encryption [R2 - Gosling - Tor - Tor - Gosling - R2] Echo Encryption

also a server can help: [Echo Encryption in R2 - Gosling] - Tor - Echo-Server Tor - [Gosling - in R2 Echo Encryption]

• the server is not central and could be any server as it is just pin in and out.
• the servers are decentral
• the servers are federateable.
• the http Listener (=Server) gets onyl encrypted packets
• the server does not know which user is connecting
• the server has no metadata
• the server has no userinfo
• the server needs no accounts
• the Listener (= server) is just ping in and ping out to all connected.

[also a p2p connection would be possible, but then the one node needs the first Tor IP (Tor-Gateway was the name?), so that needs manual fiddling].

Next to groupchat also chat to offline friends is one topic, that is all in the echo protocol and client given.