Peer-to-Peer Channel for Qabel #169
Description
Motivation
Our current architecture cannot provide transmission of live data. This even might restrict the usage of the chat module: if two parties communicate at the same time and one of these parties uses a mobile device with a mid anonymity level (shares a drop ID with ~20 users), the speed and traffic could hinder a fluent communication and spend a lot of traffic quota.
Additionally neither (video-)calls nor synchronous collaborative work (e.g., on documents) can be provided.
One solution could be the implementation of a peer-to-peer channel between the parties for specific modules or situations. Thereby the provider would lose the access to the traffic.
Draft
As soon as a module requests a live communication, such a channel could be established via drop messages. This could be realized by implementing standard protocols like SIP [1] and SRTP [2], ZRTP [3] or DLTS. Our current cryptography could be applied or used to gain a similar level of security (confidentiality, authenticity and maybe integrity).
Security: Anonymity, Integrity and Noise
An advantage of peer-to-peer channels is that the provider cannot be used to observe traffic. The main disadvantage is the loss of meta data obfuscation. Tor might be used to gain anonymity and it seems to be practical even for VoIP calls [4]. However without using Tor, the main goal of Qabel could not be reached.
Integrity of single messages (packets) would still be achieved. It should be discussed whether the integrity of the stream needs to be protected, since e.g., calls can be performed by accepting package loss.
Noise-pipes [5] – enhanced noise boxes, which we use for drop messages – are designed for the encryption of message streams and could therefore be used for the described application.
As evaluated in #127 and related issues such a channel could provide forward secrecy.
[1] https://tools.ietf.org/html/rfc3261
[2] https://tools.ietf.org/html/rfc3711
[3] https://tools.ietf.org/html/rfc6189
[4] https://guardianproject.info/2012/12/10/voice-over-tor/
[5] http://noiseprotocol.org/noise.html#handshake-re-initialization-and-noise-pipes