[kwlug-disc] Videoconference in end-to-end

[Mikalai Birukou]

>> Pretty much no video conferencing system that supports a large number of
>> participants will have end-to-end encryption.  The problem with Zoom
>> here is that they're claiming that they do.
> That's a fun mental puzzle.  If we used public key encryption,
> it would still be possible in theory.  Each person uploads one stream
> to the server, the server sends all streams to all users (with perhaps
> some out of band signaling for optimization).

Suggestion:

1) Key distribution among participants, trust -- all of these we take 
from end-to-end encrypted text chats. Therefore, we can lean on work and 
advances done there.

2) Stream from each participant we treat as one message broadcasted to a 
group. Have appropriate keys.

3) Owner of the server, or user who provides server resources, randomly 
generates ids for each participant. User instructs server to allow 
requests and streams from those who provide given ids/creds. Respective 
ids/creds are distributed to participants via end-to-end encrypted 
messaging.

4) Participants figure out keys for streams according to (1).

5) Each participant now sends encrypted stream to server. Different 
resolution streams can be assembled and streamed by participants, cause 
server is incapable of creating different resolutions of streams to 
which it has no keys.

6) Essentially server provides a multiplier that turns stream of one 
producer into many streams of consumers. As we've seen on Monday, 
bandwidth at multiplier location will always be needed.

7) Of course, all of the above steps of signals distribution should be 
done by meticulous computers. Then we can imagine that number of server 
points can be N, each with specific limits on bandwidth. But our program 
should intelligently distribute points of who's streaming and consuming 
where. And with N server resources we can imagine that many owners can 
lease these resources for a duration of the meeting.


As a result we have stream content that servers can't see, and servers 
don't know who participants are, in accordance with 3N principle (slides 
from September's talk: 
https://kwlug.org/sites/default/files/2019-09/mikalai-PrivacySafe.pdf ).

This is what I plan to try to make as a 3NWeb video messaging app. 
What's you opinion? Is there something I miss? What are possible concerns?


> Would have to trust the symmetric key with all members of the call,
> but I think it's still possible.
This or similar stuff is what they do for end-to-end encrypted group 
chats. Every implementation has its own take about trust between 
multiple members. I guess, you can create very sophisticated academic 
models, but my humble guess is that something simple is enough.