TorX: "Metadata-safe Tor Chat Library"

[TorX]

So I've made a Tor Chat C library and two proof-of-concept UI clients (one in GTK4 for Windows/Linux/MacOS/etc, and one in Flutter for Android).
https://torx-chat.github.io/
https://github.com/TorX-Chat/

See screenshots (note: a bit outdated, they don't show audio messages).

tl;dr:

• Tor hidden services with V3 authentication
• Fully P2P. The project runs no servers.
• Public groups (share by QR code or string, then join requests get encrypted and promulgate anonymously through the network until someone can decrypt it and facilitate your connection), which utilize unsigned messages
• Private groups (send an invitation card to a friend you already connect to), which utilize signed messages (which other people can re-broadcast)
• Single-use onions for friend requests (once you connect to your friend the first time, their onion gets destroyed and you both create fresh onions. This makes it safe to share friend requests over insecure methods like telephone, Twitter, etc, without the glowies being able to monitor them once your friend connects the first time)
• SQLCipher for encrypted storage of messages, settings, whatever.

It supports:

• Unlimited sized signed / unsigned text / binary messages
• Resumable File Transfers ( full duplex, pretty fast )
• Custom text/binary/streaming/etc protocols (Currently implemented in the UI: audio messages, animated gifs)

How it differs from every other Tor Chat:

• You have a unique onion for everyone you connect to, except in groups.
• Single-use OnionIDs for connecting (multi-use are also available)
• It's far faster, better, more reliable.
• It's a C library, so you can write your own UI.
• UI devs can design and implement their own protocols, without needing any modifications to the library.
• Mining of onions, so instead of 56 character long onions, you can share 48 character long ones (or shorter if you have lots of time or CPU)

I'm currently the sole developer. I've reached a plateau where development is stable and so I'm looking for devs.

Anyway, if you are interested, I'll answer questions here for a couple days and you can also hit me up on IRC. https://torx-chat.github.io/#support

Here is a multi-use TorX-ID. You can add me for the lulz. (Warning: copy it, type it right, or scan the QR code; there is no checksum)
fswyzwcizloe5anihijg5wk5q6vz7thie6dfp5uymycs5jfa

 

[Emilio Mola]

Extremely based. Pure Kino.

 

[Dante Alighieri]

My almonds are activated

 

[Kosher Dill]

The developer's friend's family member ended up on Interpol's "Red List" and the developer watched their friend struggle to maintain constant communication with their family member, sometimes going for weeks without communication, as their family member travelled the world using a combination of illicitly obtained passports and unlawful border crossings.

Threat Model

Five Eyes affiliated advanced nation state(s) with near unlimited access and resources, including the ability to compromise or drone strike users' endpoint devices, if identified.

Well. Good luck, buddy.

If your friend's mother's landlord's brother's cousin's neighbor's uncle is still alive in a year I'll consider the project a success.

 

[TorX]

Lost contact with that friend before development got to this stage. It was the inspiration but they never got to use the chat.

 

[Sperg_rancher]

This looks interesting, it seems that it's going to require users to open ports?
Also, what's up with this cryptic argument for the data directory when hashing passwords?

https://github.com/TorX-Chat/libtorx/blob/main/core/torx_core.c#L2530

char arg3[] = "FyRH0kIouynnDZmTDZpQ"; // tor_data_directory

 

[CrunkLord420]

Kiwi Farms is now the premier location for announcing your privacy respecting software. Orange Site on sewer slide watch.

 

[TorX]

I used a random string here so that there is a low likelihood that it will conflict with an actual existing directory. I think the reason I had to specify a --DataDirectory when hashing the password was to suppress a warning on Android where it might not be possible to determine one automatically. I could probably have just generated a random string rather than hard-coding one to make it look less cryptic. I'll do that.

This looks interesting, it seems that it's going to require users to open ports?
Also, what's up with this cryptic argument for the data directory when hashing passwords?

https://github.com/TorX-Chat/libtorx/blob/main/core/torx_core.c#L2530

char arg3[] = "FyRH0kIouynnDZmTDZpQ"; // tor_data_directory

Note: all my messages here are requiring mod approval. I'm presuming this is because my account is fresh, but it's slowing down my replies.

 

[Sperg_rancher]

Gotcha! Thanks for the explanation. I'm no good at reading C, so I'll take a deeper look later, but on the face it seems very sound. Without looking at the code, the only vulnerability I could think of is correlation attacks, but if you run your own ToR node on the same network as your client, that's minimized.
What's the long term plan for the project? is it going to be actively developed? are contributions welcome?

 

[TorX]

Timing correlation attacks are an issue. That's why single-use onions are preferable to multi-use. Ex: NSA can monitor the up/down times of the onion I posted in this thread (the QR code) until I disable/delete it, or until its life expires (by default, one year, but you can adjust it in settings). To avoid this, use single use onions for everyone and/or don't post your onions in public. (Single use onions are destroyed upon the first handshake)

This is also an issue for group chats, etc. For example, if you're in a group chat with 300 people, all your peers can monitor when you go online and offline. It's actually especially a problem with group chats because group chats can't utilize v3 authentication (because of arbitrary limitations on v3 authentications in Tor, which will probably be resolved when they finish re-writing in Rust), which means that if there is someone compromised within the group, an outside adversary can make anonymous connections to your group chat onion to monitor it.

The implications are: If two groups you are in are compromised by the same adversary, they can realize "BatshitKilla" in a group chat is going online and offline at the same time as "Billy from School" in another group, so personas can be correlated. If you aren't using group chats, or are keeping to small private group chats rather than massive public ones, then maybe the glowies pwn your Grandma's computer and someone you communicate operational information with and correlate the connection/disconnection times.

How to mitigate these type of issues are complex topics because they're inherent problems that apply to all Tor hidden services. If I have more developers, I'll be able to devote more time to implementing partial mitigations. However, all theoretical mitigations I can theorize have significant drawbacks and only provide partial mitigation. So far, due to limited hours of the day, I've just left this as a "Tor problem, outside the scope of TorX".

Also there should probably be warnings about these things in the UI clients. That's on the TODO list.

Gotcha! Thanks for the explanation. I'm no good at reading C, so I'll take a deeper look later, but on the face it seems very sound. Without looking at the code, the only vulnerability I could think of is correlation attacks, but if you run your own ToR node on the same network as your client, that's minimized.
What's the long term plan for the project? is it going to be actively developed? are contributions welcome?

Regarding active development: Yes, I've been working on it 2-3 years and intend to continue full-time, so long as my NEET life supports it. Contributions *very* welcome. Here is the list of contribution types sought: https://torx-chat.github.io/#contribute and here is the TODO list: https://torx-chat.github.io/todo.html

 

[I've Seen Some More Shit]

I appreciate your intentions but I think you're opening a pandora's box with this. I'm very pro-anonymity and pro-privacy, but these super-private chat programs seem to always lead to grooming dens and the creators end up getting screwed over by that. Hopefully you don't encounter any trouble because of scumbags abusing it.

 

[TorX]

I appreciate your intentions but I think you're opening a pandora's box with this. I'm very pro-anonymity and pro-privacy, but these super-private chat programs seem to always lead to grooming dens and the creators end up getting screwed over by that. Hopefully you don't encounter any trouble because of scumbags abusing it.

Thanks for the concern, but I reside outside of five-eyes countries and Europe in a non-extradition country. Besides that, all I provide is source code. I don't host anything. If I ever get black-bagged or MOSSAD'd, just fork the project.

 

[Spungus]

Oh man, I have a scrapped project fairly similar to this about a year ago, though the focus was less on privacy and more on just utilizing Tor to get around NAT. Great job!

Three questions:

Mining of onions, so instead of 56 character long onions, you can share 48 character long ones (or shorter if you have lots of time or CPU)

Is this enabled by default? If you're already sending a 48 character long code, I doubt that an extra 8 characters will matter that much, and it may lead to some profiling.

• Public groups (share by QR code or string, then join requests get encrypted and promulgate anonymously through the network until someone can decrypt it and facilitate your connection), which utilize unsigned messages
• Private groups (send an invitation card to a friend you already connect to), which utilize signed messages (which other people can re-broadcast)

Any fancy algorithm stuff, or is it just "blast out a message to each member in this chat". Nothing really wrong with the latter (except scaling), but I've been trying to track down an algorithm I saw years ago for large distributed chats.

Public groups (share by QR code or string, then join requests get encrypted and promulgate anonymously through the network until someone can decrypt it and facilitate your connection), which utilize unsigned messages

Maybe not at the protocol level, but is there any bad actor protection here? Everything else seems fine with the idea that you likely know the the person on the other won't nuke you, but if someone joins a private group, can they just start beaming huge files at everyone?



Semi-related but I wish Tor had an interface for communication rather than just sockets - my approach was to SMASH and SLAM statically compiled Tor into the binary to make it self contained, and it was kind of ridiculous that I had to not only open a socket to talk to my own process, but to also wrap connections in SOCKS for the data.

 

[TorX]

When they finish re-writing Tor in Rust, it will be possible to implement Tor without having to utilize a separate binary and SOCKS. As it is, UNIX sockets are an option, I believe, but I haven't attempted utilizing them. I have a stable SOCKS implementation in the library. EDIT: Though there are some things on my TODO list related to it, specifically "need to re-write tor_call so that all calls are on a single connection and ADD_ONION does not utilize 'Detached'" on my medium priority list.

Re: Mining of onions.
Yes, it is enabled by default. Click to the settings page and flip the toggle to disable it (which results in a 56 length), or to change the suffix length to 0 (which would result in a 52 length).
The reason it is enabled by default is because the 56 character onion strings are not just random strings. They include a checksum and version byte, in addition to 32 bytes of base32 encoded random data. They are *very* detectable, if you were Facebook, for example. TorX-IDs are far less detectable, but more research should be done into how easily distinguishable from 48 character random strings they are.

Re: fancy algorithm stuff
Scroll down to the"Message Diagram" and "Base protocols Diagrams" tables here: https://torx-chat.github.io/#howitworks
Currently, in group chats, you blast your message out to everyone. In "Invite Only" groups, messages are signed so people can re-send them. In "Public Groups", messages are unsigned so there is no potential for them to be re-sent (you couldn't trust who originally wrote it). With more development resources, this could be expanded so that messages can be passed around in a automated manner that would allow each peer to only connect to a handful of people instead of everyone, if devs put their heads together and determined that doing so made sense.
Also, currently I don't implement compression on any protocols because it would be redundant. Tor already does it.

Re: group spam
Entirely possible. There is no moderation at the moment (though you can ignore/disconnect certain peers). In "Private Groups", who invited who is tracked (though I don't think I exposed it at UI level yet, it could be put in a chart diagram), but in public groups there are no invites so there is no tracking. A smart way to do moderation would be to implement some protocols for subscription based moderation: Someone can offer to moderate for you, and then if you want to subscribe to their moderation messages, you can, and then when they send an invisible "Block Timmy" message, your client would ignore "Timmy". It would be trivially easy to implement and could be done entirely in the UI or have supplementary back-end support. I just haven't devoted the time yet.

edit: Also, it's pretty cool that you compiled Tor into your binary. It's not the direction I've gone (no regrets), but you're the first person I've heard of who has actually gone that route and I've looked at a lot of applications that utilize Tor, on both Android and Linux.

 

[Layton Mysteries]

So I've made a Tor Chat C library and two proof-of-concept UI clients (one in GTK4 for Windows/Linux/MacOS/etc, and one in Flutter for Android).

How does this compare to Tox (TOX over TOR)? I know Tox more targets encrypted communications with trusted parties than anonymous ones (as a replacement for texting or phone calls), but it can be ran over TOR fine.
One big disadvantage with Tox is that you can't recieve messages sent to you while you were offline, they are lost forever, meaning you would have to run a server connected 24/7 which you connect to if you want to use it to recieve messages on the go. Does this design face the same issue since it seems to be entirely decentralised?
Tox also supports video & audio, which is really nice, do you plan on this for TorX since you mention streaming?

Edit: I like your icon but I thought it was a coiled up sticky grabber hand until I read the license that says it is a seven headed snake.

Also, wouldn't one big factor of how anonymous it is be how many people are using it? Have you tried getting in touch with the TOR project or the FSF to see if they could look into this, I know someone was compromised by the abandonned TOR messanger recently, I wonder if they might be looking for some sort of replacement to endorse.

Orange Site on sewer slide watch.

What is orange site? (NVM found it)

 

[TorX]

Re: audio, video, streaming
The library doesn't care what protocols the UI transports. The UI just registers the custom protocol with the protocol_registration function (once) and then calls the message_send function to send theoretically unlimited amounts of data whenever it wants. If the receiving peer's library recognizes the protocol and knows how to handle it, it handles it, otherwise it just gets sent with callbacks to the UI and the UI either handles it or informs the user they received an unrecognized message type. So... yes, I've implemented streaming protocols for a few minor things, and I've implemented voice messages (an example of a protocol implemented entirely in the UI as a custom protocol), but there is nothing in the library preventing me or anyone else from going further and implementing streaming audio/video/whatever in the UI layer. Bandwidth might be an issue for video but it depends. Latency might mean a full second delay. There is still work I can do on bandwidth by expanding the use of full-duplex data transport, which is high-priority for me.

Re: offline messages
Messages are saved as sent or unsent, on disk if you have history logging enabled or otherwise just in RAM. If a message is marked as unsent, it'll send the next time the peer comes online. The exception is 'stream' type messages, which are just discarded if they can't send immediately.
(Only) In Private Group chats, messages are dated and signed, so if you send a message and it doesn't get to everyone, someone else can re-broadcast it and then it'll get to others who didn't receive it.
In all other visible base message types, messages are not signed so that they can be easily modifiable for deniability. Like, if you say "hey", I can just long-press that message in the UI (as long as it isn't signed) and edit it to "i eat fish" and that'll be saved as the message you sent me in my SQLCipher database/history.

Re: tox
Tox over TCP is just hella slow (because it utilizes relays) and unreliable, and there is no support for custom protocols. Ever try to send files over Tox? Do video or audio chat?
Also Tox over Tor has the same issue as Briar/AnonymousMessenger/Speek/Ricochet-Refresh/cwtch.im, which is that you have a single identity for everyone you connect to. Metadata.

 

[TorX]

Also, wouldn't one big factor of how anonymous it is be how many people are using it? Have you tried getting in touch with the TOR project or the FSF to see if they could look into this, I know someone was compromised by the abandonned TOR messanger recently, I wonder if they might be looking for some sort of replacement to endorse.

I'm don't want to say anything bad about the Tor Project, so I'm not going to say anything about the Tor Project. The issue you are referring to, which came to light recently, has been a known-issue since at least 2018. Along with other known issues, mitigations have been put on hold for a couple years now (and will be put on hold for a couple years more) due to all development resources being shifted to re-writing in Rust.

As for TorX's anonymity depending on how many users use it, it's complicated. TorX's hidden services are better hidden than most because they aren't as exposed and because they utilize v3 authentication (except for groups). From the perspective of it being solely based on Tor hidden services, the answer is "no, it doesn't matter how many people use it", but you have to consider how botnet modern operating systems are. Android phones are likely reporting which applications you have installed back to both Google and any other big-tech application installed on your phone, so the answer is "yes, if you are using Android". Furthermore, if you are using Windows or Mac, the answer is probably also "yes, Microsoft and Apple probably know which applications you are running". Your anti-virus provider too, likely.

There are a few other factors involved, especially on Android. Modern operating systems suck.

 

[Osama Bin Laden]

i don't remember messaging you

 

[Spungus]

The reason it is enabled by default is because the 56 character onion strings are not just random strings. They include a checksum and version byte, in addition to 32 bytes of base32 encoded random data. They are *very* detectable, if you were Facebook, for example. TorX-IDs are far less detectable, but more research should be done into how easily distinguishable from 48 character random strings they are.

Gotcha, that's better than I though (I assumed that the 56 was pre-stripped)

Re: fancy algorithm stuff
[snip]

I like the private chat model. All I can remember of that algorithm that I mentioned is that it sort of works how you described, and used a tree structure. Someday I may find it...

Re: group spam
[snip]

Had similar ideas to that in some other situations, I think it's a good model. Implementing it in the backend would probably be the best solution to allow dropping messages from a bad actor early on.

edit: Also, it's pretty cool that you compiled Tor into your binary. It's not the direction I've gone (no regrets), but you're the first person I've heard of who has actually gone that route and I've looked at a lot of applications that utilize Tor, on both Android and Linux.

I used https://github.com/cretz/tor-static (I think I bumped up the repo reference though) - I was targeting both Windows and Linux, and wanted to not have to deal with extra dependencies. Downside though is that you can't update a dependency without a full rebuild. I'll toss you the source for it if you're interested.

FYI: you can select text and it will give you a dropdown for "reply". Inserts the text into the message box, and alerts the person you are replying to

 

[Big Fat Faggot]

Looking good! I like this. There was a minor build error though, so I submitted a pull request for the fix.
Tested it out with a friend and worked right out of the box with file transfer and all, I'm feeling good about this project.

I remember GNU Jami's offline messages being slightly more resilient with the DHT storing the message for some time in case both clients are offline, I think this might be used for group messages. How does it synchronize group messages currently? The private chat way of waiting until the peer coming online and sending the message doesn't seem too feasible if there's a bunch of members. Maybe some members can store the messages and send them to peers that come online, but who to encrypt the intermediate message for seems tricky offhand, or maybe you can sign them and relay the message, which seems doable.

I'm excited for this project. I'll read through the code for now and will contribute stuff if neccesary.