Adding VOIP feature

[gegel]

Hi, Ricochet team! What about adding VOIP over Tor feature to your IM? I explored the latency of the Tor network and have some tricks to achieve a near comfortable level of voice over Tor. See my similar project Onionphone for details: https://github.com/gegel/onionphone http://torfone.org/onionphone http://torfone.org/download/oph.pdf

[xros]

@gegel that sounds great. so what're you up to?

[ghost]

IMHO, this would add unnecessary load on the Tor network.

[LuccoJ]

What unnecessary load, given that exit nodes aren't involved in this? The network is meant to be used. The "unnecessary load" mantra was/is valid when exit nodes are involved, not just for any traffic.

[ghost]

@LuccoJ Actually you couldn't be more wrong. Putting load on the entry and middle nodes will make it a slower experience for all, regardless if you're using an exit or not. Traffic goes thru the entry node and middle relays no matter if you're trying to reach a hidden service or not.

[gegel]

Sorry for being late. I think the "unnecessary load" is not a problem here because VOIP plugin uses efficient voice codecs. The general mode with acceptable voice (near GSM quality) uses AMR 4.7 kbit/s. Under VAD generates approximately only 2.5 kbit/s. This is comparable with browsing and significantly less then typical downloading in Tor. And PTT mode even less cost. I can suggest few variants of realization the VOIP plugin: external daemon with UI, shared library (so) with specified API; C code as a part of project. And different functionality:

1. with own sockets and crypto layer (connected to Tor specified port in parallel with messenger);
2. with data interface passes compressed but not yet encrypted VOIP data to/from messenger for further encryption/transporting over Tor. Note: for decreasing overal latency we must use at least 2 independent Tor channels (usually this is direct connection originator - acceptor and reverse connection acceptor - originator using for authentication like Abadi protocol in TorChat etc.), doubling all VOIP data, using the first received packet, measuring statistics and periodically resetting slower channel. And both options assume own low level audio interface (alsa/wave) similarly as in OnionPhone (android low level audio is available too).

[ghost]

I don't understand why you would add any kind of load whatsoever to the Tor network, big or small, for something that isn't really suited for TCP, especially not with high latency. Pretty sure people who enjoys anonymity and all that stuff doesn't use Tor to do VOIP or anything of that sort.

Just fucking drop it.

[rodneyrod]

@norwack is this really the forum for that kind of tone? I thought we were supposed to be more civil here.

[LuccoJ]

@norwack Then let's not use the Tor network at all for any reason, that way the load on the entry and middle nodes will be minimal.

[rburchell]

Please keep comments civil. There's absolutely nothing here warranting that sort of language, and it doesn't add anything useful to the discussion.

On a related note, while doubtless, I'm sure it's possible to come up with plenty of reasons why this is (or isn't) a good idea, I don't think anyone here is in a position to dictate what others can or cannot spend their time on. That's one of the beautiful things about open source software (for better or worse ;)).

I don't know what @special's thoughts are about this sort of thing, though. We did talk about something like this, but that was a mention in passing based on me thinking "hey, something to not have to use Skype would be pretty nice", something like a year ago.

[special]

Thanks, @rburchell.

I'm not worried about additional load caused by VOIP. It's minimal compared to even many types of web browsing, and after all, the Tor bandwidth exists so it can be used in useful ways. This would be one.

I have two broad concerns:

• Latency is high for interactive voice; I'm still not convinced that the experience will be good on average.
• The codec is a significant attack service. I would want one implemented in a memory-safe way.

The onionphone work is interesting, especially as a proof of concept in how the latency problems can be mitigated.

[gegel]

About Tor overload: see some papers: http://www.diva-portal.org/smash/get/diva2:655064/FULLTEXT01.pdf https://www.uni-bamberg.de/fileadmin/uni/fakultaeten/wiai_lehrstuehle/praktische_informatik/Dateien/Forschung/Tor/wilms-performance-evaluation-of-tor-hidden-services.pdf

And good research of VOIP performance in Tor: https://ediss.uni-goettingen.de/bitstream/handle/11858/00-1735-0000-0022-5EF2-D/Dissertation%20Maimun__Rizal_final.pdf

You can also try the OnionPhone for practical evaluation the acceptability of voice. And do not forget about the PTT mode.

Also many people don't worry about strong anonymity but worry about metadata collection. It's almost even more important such as a can prevent total automatic wiretapping in application servers (Skype, SIP, Viber). You can use Tor only for searching/connection of contact in onion, key agreement and NAT traversal, after this switch to direct p2p UDP encrypted connection. Quality VOIP with no registration, not block-able, no metadata, no MitM, there is Tor-based authentication and PFS etc.

PS: Codec vulnerability is really a problem, yes. Some input data sequences can cause unwanted effects in most codecs. Also DSP code is ideal place for masking backdoors. Memory-safe implementation and security revision of codec source is my dream too. Maybe military standards (MELPE etc.) are more trusted but they are not free at all.

[ghost]

@gegel Sounds like you're describing Tox, see https://tox.chat/

[gegel]

Tox can connect to the target over Tor (probably including onion) using TCP: https://wiki.tox.chat/users/tox_over_tor_tot But I don't know about hybrid mode when TCP over Tor uses for NAT traversal (using a selectable STUNs for discovering user's IP and UDP ports) to install a parallel UDP connection for multimedia. This mode involves the use of a secure and authenticated over-Tor connections for signaling instead of the SIP server. Media transfer mode over Tor (RTP over TCP), respectively, similar to the use Tor instead of the TURN server.

[special]

@gegel

You can use Tor only for searching/connection of contact in onion, key agreement and NAT traversal, after this switch to direct p2p UDP encrypted connection. Quality VOIP with no registration, not block-able, no metadata, no MitM, there is Tor-based authentication and PFS etc.

This design abandons anonymity and leaks metadata (to any network adversary via the peer-to-peer UDP packets). Any traffic outside of Tor is outside of Ricochet's scope.

[gegel]

I fully agree with the Ricochet's scope and sound hybrid mode only as a new concept for other applications. Onion Phone supports this but direct UDP connection creates only with the permission of both participants after authentication and key agreement into Tor. This will be useful in some cases but users must clearly understand that they are doing. And it discloses only the fact of the connection between two IP, there are no metadata leaks because only PFS-encrypted pseudorandom data passes over UDP. All existing VOIP solutions with a central server and registration even more vulnerable now. But what about your vision of practicability and technical ways to apply VOIP over TCP over Tor as an optional extension of Ricochet?

[HulaHoopWhonix]

I don't know if it fits your performance constraints but Opus is a modern codec whose authors seem to understand security implications and code for it:

https://mf4.xiph.org/jenkins/view/opus/job/opus-draft/ws/doc/draft-ietf-codec-opus.html#security