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.
When remote is detected as recording this sound will play if the setting is enabled.
edit: https://veilid.com/
Added link for clarity. Seems like you could get more or less realtime, udp streaming, full duplex communication . Once you have the first part of that built, then adding things like voip or video calls or what have you becomes a lot easier.
I know you can set up mumble over Tor but it's going to have the same latency drawbacks.
Another commenter noted the ability to configure only 1 hop instead of the standard 3. I wonder how much latency would be gained back. I want to play around with this.
You could use tor to anchor a common relay, then do key and route exchange to establish veilid, then the realtime app uses that for a very secure private route unique to the two endpoints.
From what I can tell, because of the design, veilid would be excellent, comparable to many commercial voip offerings, with 150-500ms latency . More nodes and users would quickly ramp that up. There are a ton of downstream benefits of something like this; faster file exchange for ipfs, bittorent, etc, that doesn't gum up the tor layer, a kind of implicit defense in depth, but also low latency, efficient peer to peer routing.
It'd almost be zero knowledge by construction; you could build a multi-hop escrow style key exchange.
If Musk integrated tor relays and veilid peers throughout Starlink, you could get near-native latency for wherever you connect in the world, more than enough to add timing attack noise and layer in other security features.
Modulo cool project love show HN etc.
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.
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.
It still supports a bunch of outdated crap including (on my system) RC4, RC2(!) and DES (yes, the 56 bit key one, not just 3DES).
So in addition to a sensible default I guess it would also be a good idea to tag choices that you believe to be outdated with a large warning. That way you haven't rolled your own crypto, you haven't forced your views on others, but you have done your best to enable end users to operate your tool in a sensible manner.
Within the last 12 months, I had to write a script for a buddy at work that turned off availability of freaking freaking 56 bit DES in OpenSSH, which was available because was provided by openssl. I'm certain it was still there to provide compatibility for something(s) critical out there that depends on it, and while I can't imagine why anybody would choose to use it, it's there and it's awful.
Rather than what is accepted as the strongest ciphers I prefer ciphers not optimized by CPU's and GPU's. Spooks will have to cycle through every combination of protocol + cipher + mac + mode + passphrase + whatever other obfuscation I shim inside that tunnel. Keep 'em on their toes. Even better I will also cycle through these encoding methods [1] if I am in a good mood otherwise I will rot13 their ass and then force them to use a Drogan’s Decoder Wheel.
I think it's a pretty light background process.
This way you could establish communication with an unknown future party, totally offline.
[1] https://0x.co
If you're printing something why not go with a QR code?
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 ...
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.
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.
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 ).
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!
Thanks for contributing!
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.
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.
'|| 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)
Basically IRC, but for Tor.
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.
Do you mean IVs? Can't you (for most algorithms) just use a monotonic counter when streaming blocks?
> optional hmac authentication
Wouldn't that just be done per-chunk instead of per-file?
by the spooks that wrote it. no harm in having another turtle in the stack.
It's not really a latency saver but it definitely reduces load on the network.
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.
send.vis.ee along with ffsend[0] maybe?
0: https://github.com/timvisee/ffsend
I love and use ffsend every day.