Using a v3 onion address as both the cryptographic identity and the NAT traversal layer is such a clean architectural choice. No STUN/TURN servers, no hole punching, you just boot the script and Tor handles routing.
For those who use Tor regularly for things other than web browsing: how bad is the real-world latency for pushing a ~20KB Opus audio chunk over Tor these days? Are we talking a 2-3 second delay, or is it much worse?
The real world delay is about 2-3 seconds your spot on. I initially started with a full duplex version but it was absolutely terrible. Walkie talkie kinda forces the recieve, listen, response from the users so the latency isn't as much of an issue.
Is audio transmitted while it is being recorded or afterwards? Is it played before everything is received or is everything buffered? In the later case, I find it more akin an audio message on Signal or similar, than as a walkie-talkie, which is much more "dynamic".
It's not streamed. It gets recorded, compressed, (voice effects if you want), encrypted on device, then piped through, reverse process, auto played on reciever end.
Also, once it's decrypted and played back, the message gets destroyed.
Small suggestion, maybe you should send a “key down” notice when you begin recording, that generates a subtle sound on the receiving end. This would act as something like a typing indicator on a text messaging client.
STUN/TUN are important because of bandwidth. With STUN the bandwidth used is only between the two connected devices, with VPN like Tor there is a bandwidth cost on all the servers where this data is passing. This is a big blocker for anyone hosting the service on a VPS with a few GB of traffic data per month.
Very cool, happy to see more IRL applications of onion services as a backend. Arti onion client support should soon be available, which will make Tor embeddable in applications as a Rust library. Hopefully this encourages even more usage.
More applications using the network means more cover traffic as well.
Neat concept — using a .onion address as identity is elegant because it sidesteps the whole "how do you bootstrap trust" problem that kills most P2P communication tools. The hidden service keypair essentially becomes your asymmetric identity for free.
Curious about the walkie-talkie tradeoff though. Is the push-to-talk model a deliberate design choice for anonymity reasons (avoiding real-time stream analysis), or just a constraint of routing audio through Tor? Because real-time voice over Tor has notoriously bad latency — I'd guess 300–800ms round trip depending on the circuit — which would make full-duplex conversation painful. The chunked approach sidesteps that nicely but changes the UX significantly.
A few things I'd want to know before trusting this for anything sensitive:
What cipher and key exchange are you using? "End-to-end encrypted" covers a lot of ground.
How are you handling the authentication step when two parties connect? Is there any verification that you're talking to who you think, or is it purely anonymous?
What happens to the audio chunks on disk between record and transmit — are they written to disk at all or kept in memory?
The "no server, no accounts" angle is genuinely compelling. Most "private communication" tools still have a server that knows your metadata even if they can't read your messages. This architecture avoids that entirely which is the right call.
The library is openssl and that comes with all these ciphers available. No other reason than because we can!
I wish AES-GCM was available...but openssl can't do it on its own without further dependencies to parse the authentication correctly.
Really this whole layer is complelty redundant actually. It's already E2EE without openssl via Tor. I like that it's encrypted before I hit the network pipe though.
If a library doesn't do what you need, you need a different library, but this is impossible from a short bash script, so it's one of the tradeoffs of your design.
Then maybe your scientists should spend some time to stop and consider whether they should ;)
But seriously, I'd just limit this to one option on the selection side, even if you continue supporting more than that at the protocol level for cryptographic agility.
I would rather avoid cipher fixation. Give me thousands of protocol / cipher / mac / mode combinations. Fixation only benefits nations wanting to crack something.
> Exclude Countries -- Exclude specific countries from your Tor circuits. Presets for Five Eyes, Nine Eyes, and Fourteen Eyes alliances, or enter custom country codes. Uses ExcludeNodes with StrictNodes in the torrc.
Interesting that people do this, I wonder how much it improves security? Afterall, any serious surveillance would involve running relays and exits in foreign lands.
This was another one of those things I built in because we can. I really don't know... But the Tor developers built this in as an option on the torrc so there must be something to it. We know there are definitely compromised nodes...I think it's just neat that you can have that level of control regardless if it's effective.
Forgive my ignorance, but can this be setup for a group like how a group can all be on the same frequency with walkie talkies? Or it is strictly one to one. Either way, it’s a really cool concept.
It actually can since its just symmetric encryption. Any key holder could decrypt the payload. In fact, the channel could simply be the shared secret.
Let's say we have 10 people in a call, 5 share a key and the other 5 share a different key. Without the shared key audio simply will not decrypt. You could have two private channels with one host.
Thanks! My realistic use case is that I am already speaking to someone who I know and trust, so ideally exchange credentials in person. A preferred out of band secure messanger of choice is probably fine.
The walkie-talkie model is a smart design choice given Tor's latency profile. Real-time bidirectional audio has pretty unforgiving requirements (~150ms round-trip max before it feels awkward), and Tor typically adds 50-200ms per hop. Going store-and-forward sidesteps the whole problem—you're not fighting the network's characteristics, you're designing around them.
Curious what codec you're using for the audio compression. Opus would be the obvious choice for speech but the tradeoffs change a bit when you're not doing real-time streaming.
I love it for the same reason I love email and text communication. Think about what you want to say before you say it. Exclude the useless tangents: formalities, movie quotes, humble brags, cliches, etc. A few second delay is enough to get even the worst offenders to get to the point.
Yes it's encoding in opus, and optionally you can configure encoding quality from 6kbs to 64kbs.
I was really surprised at the intelligability even at 6kbs.
The caviot is if your on termux we have to use the seperate termux API application to pipe audio to termux, and ffmpeg to convert MP4 to opus. Unfortunately termux cannot activate the mic on its own.
By MP4 I assume you mean AAC in MP4. I'm a bit confused by this. What emits AAC that then needs transcoding to Opus? Not that transcoding losses really matter for this application, but the pipeline is not clear to me?
So this is only for termux compatibility. On a standard distro it skips this step entirely and goes straight from raw pcm to opus.
On termux 'termux-microphone-record' is a wrapper around androids 'mediarecorder'. It doesn't support raw pcm output. It records AAC in m4a wrapper and then the extra ffmpeg package converts this to rawpcm so it can follow the same pipeline.
You may like this one then. It's kinda the same thing, but text only and multiple people can connect at once. It's setup so anyone can be a host, or a client.
Oh I’m curious. Love bash, and learning new things about it.
I can understand why [ is not ideal. Can you explain the rest to me? I use || true for custom error handling often (with the right set -euo pipefail of course)
Still: Using a line based protocol and base64 encoding the audio data? Not my first choice.
The README doesn't mention it, but I assume both parties have to be online at the same time?
Regarding encryption - what's the point? When communicating with a tor hidden service, the data is already encrypted.
Only starting the sending audio data after the speaker has stopped talking means much longer delays than necessary. Imagine someone talking for a minute.
To receive a call, you either need to be online and actively listening for calls, or optionally, you can enable auto listening. When another user calls you it will automatically put you in the call. On end call you will be put back in listening mode. I'm not really sure a great way to get around this without overly complicating it.
I believe because of the small overhead that's added there is just no reason not to layer encryption. At the end of the day I just wanted to see the bits I'm sending over the wire with my own eyes for assurance it's protected regardless of the fact that tor is protecting the data.
The streaming would be a nice improvement for latency. I would have to look into how this would work for the optional audio processing. Having one set file for transport also simplifys the some of the flow with encryption like salting and optional hmac authentication as these are derived from the sum of the entire file, not a portion of it.
The base64 encoding adds about 30% overhead. It's not ideal but it was a limitation of bash. Passing raw binary does not work in bash (or I couldn't get it to work).
Sorry for hijacking but I came across a firefox send replacement which worked in linux command line. Anyone know what it was? (It was online though, as in no storage for later)
Looks awesome in many ways. The use of a shared secret instead of PKI limits the real-world applications pretty severely, but adding PKI support doesn't seem too difficult. If the PKI key was only used to establish the session "shared secret", virtually no changes would be needed in the main code.
For those who use Tor regularly for things other than web browsing: how bad is the real-world latency for pushing a ~20KB Opus audio chunk over Tor these days? Are we talking a 2-3 second delay, or is it much worse?
Also, once it's decrypted and played back, the message gets destroyed.
More applications using the network means more cover traffic as well.
What cipher and key exchange are you using? "End-to-end encrypted" covers a lot of ground. How are you handling the authentication step when two parties connect? Is there any verification that you're talking to who you think, or is it purely anonymous? What happens to the audio chunks on disk between record and transmit — are they written to disk at all or kept in memory?
The "no server, no accounts" angle is genuinely compelling. Most "private communication" tools still have a server that knows your metadata even if they can't read your messages. This architecture avoids that entirely which is the right call.
Why!? That sounds like approximately 20 too many.
I wish AES-GCM was available...but openssl can't do it on its own without further dependencies to parse the authentication correctly.
Really this whole layer is complelty redundant actually. It's already E2EE without openssl via Tor. I like that it's encrypted before I hit the network pipe though.
great attitude for approximately everything except, perhaps, cryptography.
especially since the initial encryption is mostly redundant, i would encourage that you, at some point, consider reducing the number of ciphers.
Then maybe your scientists should spend some time to stop and consider whether they should ;)
But seriously, I'd just limit this to one option on the selection side, even if you continue supporting more than that at the protocol level for cryptographic agility.
Interesting that people do this, I wonder how much it improves security? Afterall, any serious surveillance would involve running relays and exits in foreign lands.
Let's say we have 10 people in a call, 5 share a key and the other 5 share a different key. Without the shared key audio simply will not decrypt. You could have two private channels with one host.
I think it's a pretty light background process.
Curious what codec you're using for the audio compression. Opus would be the obvious choice for speech but the tradeoffs change a bit when you're not doing real-time streaming.
I was really surprised at the intelligability even at 6kbs.
The caviot is if your on termux we have to use the seperate termux API application to pipe audio to termux, and ffmpeg to convert MP4 to opus. Unfortunately termux cannot activate the mic on its own.
Very interesting project, by the way.
On termux 'termux-microphone-record' is a wrapper around androids 'mediarecorder'. It doesn't support raw pcm output. It records AAC in m4a wrapper and then the extra ffmpeg package converts this to rawpcm so it can follow the same pipeline.
Basically IRC, but for Tor.
https://gitlab.com/here_forawhile/torch
'|| true' 76 matches 'echo ""' 50 matches ' [ ' 261 matches '=$(' 90 matches
I can understand why [ is not ideal. Can you explain the rest to me? I use || true for custom error handling often (with the right set -euo pipefail of course)
Still: Using a line based protocol and base64 encoding the audio data? Not my first choice.
The README doesn't mention it, but I assume both parties have to be online at the same time?
Regarding encryption - what's the point? When communicating with a tor hidden service, the data is already encrypted.
Only starting the sending audio data after the speaker has stopped talking means much longer delays than necessary. Imagine someone talking for a minute.
To receive a call, you either need to be online and actively listening for calls, or optionally, you can enable auto listening. When another user calls you it will automatically put you in the call. On end call you will be put back in listening mode. I'm not really sure a great way to get around this without overly complicating it.
I believe because of the small overhead that's added there is just no reason not to layer encryption. At the end of the day I just wanted to see the bits I'm sending over the wire with my own eyes for assurance it's protected regardless of the fact that tor is protecting the data.
The streaming would be a nice improvement for latency. I would have to look into how this would work for the optional audio processing. Having one set file for transport also simplifys the some of the flow with encryption like salting and optional hmac authentication as these are derived from the sum of the entire file, not a portion of it.
by the spooks that wrote it. no harm in having another turtle in the stack.
Thanks for contributing!