6 ms·
Show HN: Terminal Phone – E2EE Walkie Talkie from the Command Line
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.
- marcosqanil 8mo agoI love this. In your view, how would users go about securely swapping credentials ? PGP over email ?
- deleted 8mo ago[deleted]
- smalltorch 8mo agoThanks! 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.
- deadbabe 8mo agoWhat do you guys talk about?
- smalltorch 8mo agoI 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.
- clouedoc 8mo agoThat's funny but it must absolutely drain the battery of her phone, no?
- smalltorch 8mo agoSo far it's lasted all week with maybe 10% -15% loss per day. It's not her main, actually just a old phone I had laying around. I think it's a pretty light background process.
- rsync 8mo agoYou could put your onion address into an “oh by code”[1] and just write it down … or chalk it on the sidewalk for someone to see … post it on a physical bulletin board.. hold it up on a sign… This way you could establish communication with an unknown future party, totally offline. [1] https://0x.co https://0x.co
- fc417fc802 8mo agoTrying to repurpose hex literal notation as a "recognizable" URL shortener seems like a questionable idea. At least write it as 0x.co/FFFF so it's obvious to readers how to interpret it. If you're printing something why not go with a QR code?
- rsync 8mo agoIf you can use a QR code you probably should. However, if you're walking down the street and need to quickly generate and apply a message, how will you pass along a QR code to an unknown future viewer ? Can you draw a QR code with chalk or freehand with a pen, etc. ? I will admit that the use-cases for "oh by codes" are weird and infrequent but I am convinced they will emerge ...
- fc417fc802 8mo agoI don't disagree that URL shortening is incredibly useful at times. Merely that writing out the whole url is almost certainly a better approach and that any sufficiently short domain name is fit for purpose.
- Pinkert 8mo agoUsing 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?
- idiotsecant 8mo agoBeep boop
- smalltorch 8mo agoThe 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.
- ale42 8mo agoIs 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".
- smalltorch 8mo agoIt'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.
- iamnothere 8mo agoSmall 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.
- rustyhancock 8mo ago> 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.
- smalltorch 8mo agoThis 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.
- kortilla 8mo agoIt might not help for controlled nodes, but it does help avoid ISPs controlled by said governments from seeing it
- oybng 8mo agoLooks fun, I've yet to test it but I did skim it. '|| true' 76 matches 'echo ""' 50 matches ' [ ' 261 matches '=$(' 90 matches
- nebezb 8mo agoOh 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)
- lxgr 8mo ago> 21 curated ciphers are available Why!? That sounds like approximately 20 too many.
- smalltorch 8mo agoThe 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.
- lxgr 8mo ago> 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.
- Bender 8mo agoI would rather avoid cipher fixation. Give me thousands of protocol / cipher / mac / mode combinations. Fixation only benefits nations wanting to crack something.
- Tepix 8mo agoInteresting 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.
- smalltorch 8mo agoThe 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).
- extraduder_ire 8mo agoWhat exactly was the problem you ran into? I've run binary through pipes just fine before.
- smalltorch 8mo agoyour right it's not a problem. This has been implemented since v1 and I haven't really been focused to much this. Trying to decide if I should remove this step for future versions. It's a clear optimization but Im thinking it should at least be backwards compatible with old versions. It's not really a latency saver but it definitely reduces load on the network.
- snthpy 8mo agoI was also curious about the base64 encoding in the stack. I'm not knowledgeable in this area though so it was more for my own education than questioning the choices.
- smalltorch 8mo agoIts a product of me troubleshooting why my audio pipe wasn't working in early prototyping. I tried quite a few things and the first time I got the successful loopback on a remote device I had implemented the base64 and it solved the piping errors I was getting. Turns out bash totally can pipe raw binary you just need to appropriately wrap the blob with the correct command. By the time I had the working pipe I was in feature building mode.
- decker_dev 8mo ago[dead]
- smalltorch 8mo agoYes 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.
- encom 8mo agoBy 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? Very interesting project, by the way.
- smalltorch 8mo agoSo 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.
- kgwxd 8mo agoI 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.
- bstsb 8mo agoyou're not just formulaic, you're an entirely ai-generated comment
- mrexcess 8mo agoLooks 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 8mo agoThis 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 8mo agoVery 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 8mo ago> 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 8mo agoSorry 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)
- zie 8mo agoFirefox Send is still around in hobbyist land: send.vis.ee along with ffsend[0] maybe? 0: https://github.com/timvisee/ffsend https://github.com/timvisee/ffsend I love and use ffsend every day.
- aitchnyu 8mo agoTangential, did Gitlab become faster than a while back or is it an illusion from their lazy loading?
- sailorganymede 8mo agoI worked on text chat ages ago over TOR. Honestly so happy to see that the ecosystem is still going!
- smalltorch 8mo agoYou 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. Basically IRC, but for Tor. https://gitlab.com/here_forawhile/torch https://gitlab.com/here_forawhile/torch
- ProofHouse 8mo agoThis is rad
- chasd00 8mo agoForgive 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.
- bzmrgonz 8mo agoI don't think E2EE works that way.
- cl3misch 8mo agoI think it does? How would Whatsapp or Signal group chats work then?
- smalltorch 8mo agoIt 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.
- smalltorch 8mo agoIt's strickly 1 on 1 for now but I do plan on exploring the group call scenario.
- codingrot17 8mo ago[dead]
- driftbyte62 8mo agoI'm genuinely curious: what do you hope to gain by posting AI generated comments?
- smalltorch 8mo agoWhen I started prototyping it's started as full duplex. I was up for the challenge and wanted to understand why this already didn't really exist. It ended up being awful. A standard real time call your able to interject and talk over someone and this works because of the low latency. The other person can stop talking and the conversation still flows. The latency from Tor just makes it awkward to the point that you have to almost relearn how to have a conversation since by the time your interjecting and they hear the interjection, a whole 6 seconds may have passed and they may already be on a whole other train of thought. Walkie talkie architecture just forces you to listen and digest the message, think, respond. There are two layers of encryption here. Tor, which already is encrypting the data, and locally via openssl before transmit. I have 21 ciphers programed in from the openSSL library. There's a lot more available in the library but these are supposedly the strongest. The cipher used is not secret so while in the call you can see your cipher, and the remote cipher real time. The authentication is resting entirely in the users lap. It's up to them how to come up with key exchange. For me, I would be comfortable enough knowing the other side is who I think it is by the simple fact that audio is passing through. Establishing a connection once in person is most ideal. Because the .onion is derived on device, an attacker can't just forge that. You need also need the private key for a connection to be established. Let's say an attacker copies the directory from one of the endpoints and has the private key now and can launch tor under your static address. Well, because the additional shared secret is encrypted with another password known only to the user it's useless. The other side will not be receiving forged audio because of this barrier. They may get as far as being in a call, but no audio is going to be played back because the shared secret was successful protected. Even if you pass your message to the attacker, decryption will fail and nothing will pass. Directly after sending, we run rm -f on $raw_file, $opus_file, $enc_file. Audio is recived to /audio folder. After audio is decrypted and played we run rm -f $enc_file, $dec_file. There is only a split second that it lives on disk until it's gone.
- m00dy 8mo agoI tried using https://letscage.com https://letscage.com for this. Almost same design but in rust
- nullc 8mo agoSince 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 8mo agoI am totally interested in a 2kbs encoding if that's possible. I didn't think opus could encode below 6. Making this as slim as possible is definitely what I'm aiming for. Really though the latency basically all coming from Tor. Someone also suggested that you can configure Tor to take only one hop. You loose anonimity but gain speed right away. May be something to look into as optional setting. I also learned today I can pipe direct binary without encoding base64. This will chop overhead right away. I didn't think it was possible to pipe through bash but I was using the wrong command. I do plan to continue to optimize that's great feedback thanks!
- smalltorch 8mo agoFor 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.