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.
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.
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.
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)
> 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.
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.
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.
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).
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.
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.
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.
Beep boop
> 21 curated ciphers are available
Why!? That sounds like approximately 20 too many.
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.
> No other reason than because we can!
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.
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)
> 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.
It might not help for controlled nodes, but it does help avoid ISPs controlled by said governments from seeing it
I love this. In your view, how would users go about securely swapping credentials ? PGP over email ?
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.
What do you guys talk about?
I have my wife's phone set up on autolisten running in the background, so I just pop in and ask how her days going and crack jokes.
Looks fun, I've yet to test it but I did skim it.
'|| true' 76 matches 'echo ""' 50 matches ' [ ' 261 matches '=$(' 90 matches
Interesting to implement this as a shell script.
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.
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).
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.
Thanks for contributing!