3 ms·

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'

by Tepix 8mo ago

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.

smalltorch 8mo ago
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).
- extraduder_ire 8mo ago
  What exactly was the problem you ran into? I've run binary through pipes just fine before.
  - smalltorch 8mo ago
    your 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 ago
  I 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 ago
    Its 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.
Bender 8mo ago
the data is already encrypted by the spooks that wrote it. no harm in having another turtle in the stack.
- Tepix 8mo ago
  If you don’t trust tor, why use it?
  - Bender 8mo ago
    I don't trust anything or anyone. Rather I just use defense in depth and assume someone at some point will get access to the data.
    - Tepix 8mo ago
      Well, it's not adding post-quantum crypto which might be more important than yet another layer of AES.
smalltorch 8mo ago
To expound on the other questions. 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.
- fc417fc802 8mo ago
  > salting 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 Tepix 8mo ago

smalltorch 8mo ago

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

extraduder_ire 8mo ago
What exactly was the problem you ran into? I've run binary through pipes just fine before.
- smalltorch 8mo ago
  your 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 ago
I 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 ago
  Its 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.

Bender 8mo ago

the data is already encrypted by the spooks that wrote it. no harm in having another turtle in the stack.

Tepix 8mo ago
If you don’t trust tor, why use it?
- Bender 8mo ago
  I don't trust anything or anyone. Rather I just use defense in depth and assume someone at some point will get access to the data.
  - Tepix 8mo ago
    Well, it's not adding post-quantum crypto which might be more important than yet another layer of AES.

smalltorch 8mo ago

To expound on the other questions. 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.

fc417fc802 8mo ago
> salting 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?