HN Explorer

Show HN: Terminal Phone – E2EE Walkie Talkie from the Command Line (gitlab.com)

322 points by smalltorch ↗ HN
TerminalPhone is a single, self-contained Bash script that provides anonymous, end-to-end encrypted voice and text communication between two parties over the Tor network. It operates as a walkie-talkie: you record a voice message, and it is compressed, encrypted, and transmitted to the remote party as a single unit. You can also send encrypted text messages during a call. No server infrastructure, no accounts, no phone numbers. Your Tor hidden service .onion address is your identity.

23 comments

[ 2.5 ms ] story [ 49.7 ms ] thread
marcosqanil
I love this. In your view, how would users go about securely swapping credentials ? PGP over email ?
Pinkert
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?

medi8r
Why not stream anyway? adding to the latency by turning it to audio messages sounds more frustrating. At some point a message would be better.

Modulo cool project love show HN etc.

rustyhancock
> 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.

oybng
Looks fun, I've yet to test it but I did skim it.

'|| true' 76 matches 'echo ""' 50 matches ' [ ' 261 matches '=$(' 90 matches

lxgr
> 21 curated ciphers are available

Why!? That sounds like approximately 20 too many.

Tepix
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.

[dead] decker_dev
[dead]
bstsb
you're not just formulaic, you're an entirely ai-generated comment
mrexcess
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!

smalltorch
This would be a great improvement and I'm going to look into how to implement!

The most obvious path is just integrating the authorized clients Tor has already built in. A way to export these keys efficiently to your intended recipient.

iamnothere
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.

xnyan
> More applications using the network means more cover traffic as well.

Agree. The biggest barrier for me using Tor is the perception held by many IT admins is that Tor is synonymous with nefarious. It makes using it inconvenient or impossible in many highly controlled network environments such as enterprise, public access wifi, etc.

sourcegrift
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)
aitchnyu
Tangential, did Gitlab become faster than a while back or is it an illusion from their lazy loading?
sailorganymede
I worked on text chat ages ago over TOR. Honestly so happy to see that the ecosystem is still going!
chasd00
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.
nullc
Since you're not realtime you could also have a configurable playback speed on the rx side or processing that removes gaps to make it go faster. This would improve the latency while maintaining the whole store/forward design, and would also let a recipient get more than 100% audio (e.g. from multiple people sending to them).

You're using opus but you might be interested in abusing the DRED error correcting scheme (which is an experimental part of opus) in it as a codec, as it does pretty good sounding speech at 2kbit/sec. You could send the dred first then the opus compressed audio so that if tor craps out before the transmission completes the receiver still get the audio. (A step further would be to run automatic speech recognition, a send text, dred, then opus. :P ).

smalltorch
For anyone following 1.1.5 now has support for group calls. Now use terminalphone as a dedicated relay. All users connect to the relay and the messages will be broadcasted to everyone in the group.

A mobile relay should be able to handle 3-5 users nicely. A dedicated machine with a stable connection should be preferred.

You can act as the relay and caller by running two instances, you will need to change your socks port of the second instance so that you can have two addresses.

Relay does not need to have the shared secret, it is simply forwarding payloads, and broadcasting connected client counts.