17 ms·

What end-to-end encryption should look like

245 points by lopespm 6y ago

kodablah 6y ago
I have a question on the definition of "end-to-end encryption" with regards to groups/rooms. Is it sufficient to have a single key shared by all "ends" for the room, or must each user have its own key? If a single group key is acceptable, must it be rotated as a member goes or comes? I'm just looking for common definition of the term wrt webrtc groups for fear of misusing it when describing a product. (for the purposes of this clarification, pretend I have key distribution/derivation figured out and I whether I use asymm or symm encryption doesn't apply to the question itself)
- otachack 6y ago
  I think it's a hot topic and the definition is divisive. Having 1 "secret" that end users share and use is technically end to end encryption, I'd say, but it's kind of like sending messages to yourself. It's kind of like setting up one private/public key pair, then sharing both with everyone in your group and writing each other messages with them. If one of your group become a malicious actor, or if a malicious actor manages to steal the pair, it can compromise the group communications. You also can't cryptographically distinguish between each other since you share one identity. Mix in video conferencing, though, and you really just have to trust what you see/hear from your peers video feed in addition to trusting your shared key pair isn't compromised. Ideally, each party member has their unique key pair, they share their public keys between the group, then communicate that way. But you got more overhead in starting a Jitsi meet room rather than just a link and a shared password.
  - warkdarrior 6y ago
    Separate keys means you need to have separately encrypted streams for each pair of participants. This is probably not scalable, and definitely does not play well with multicast or with a video-routing server.
    - notduncansmith 6y ago
      I think a strong cryptographic communications platform would offer the option of using either multi-party-shared-key or p2p key pairs depending on the use-case. Similar to how Slack has both private and public channels within an org.
    - the8472 6y ago
      Not really. You can have internal per-packet keys which you throw away after your cryptographic setup and then only convey that key in separately in some encrypted form to each member along with a common payload which is amenable to multicast. I think that's a piece of signal's group chat protocol.
    - adrianmonk 6y ago
      Is that really true? I'm not a cryptographer by any means, but it seems like every time you transmit a chunk of video over the network, you could generate a single-use key, encrypt the video with that key, and then encrypt the single-use key with every intended recipient's individual key. When the recipients get the message, they'd find their encrypted copy of the temporary key in the list, recover the single-use key, then decrypt the video. That way the only wasted bandwidth is in transmitting keys, which is a lot smaller than video. The recipients could give the single-use key (that they decrypted with their individual key) to someone who isn't supposed to have it, but that doesn't seem like a problem since they already have the decrypted data and could give that away. For a small performance improvement, you could re-use the temporary key a few times (for, say, 10 seconds) if the set of intended recipients doesn't change.
      - 0xBeefFed 6y ago
        I am not sure if this relates, but this past year at Blackhat there was a talk on Messaging Layer Security and they broughtup a concept called TreeKEM, where users share keys in a tree heirachy to reduce the number of shared secrets. Again, not sure if this is applicable, but the comments made me think of this. [0] https://www.blackhat.com/us-19/briefings/schedule/index.html#messaging-layer-security-towards-a-new-era-of-secure-group-messaging-16230 https://www.blackhat.com/us-19/briefings/schedule/index.html... [1] https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messaging-Layer-Security-Towards-A-New-Era-Of-Secure-Group-Messaging.pdf https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messagi...
- crazygringo 6y ago
  I think it's very much a gray area. True E2EE seems like each endpoint would have to have its own key. But the bandwidth realities of group videoconferencing make it entirely infeasible for each participant to be sending a separately encrypted stream to each other participant. So the only realistic solution is for all members to share the same key, which makes everything dependent on the security of the key distribution. But then... is it really E2EE? I'm not sure there's a generally accepted answer here.
  - sarakayakomzin 6y ago
    > So the only realistic solution is for all members to share the same key, which makes everything dependent on the security of the key distribution. But then... is it really E2EE? each member deriving their own key and coming to an agreement on the client side is e2ee; it's primarily about the server not having knowledge or being able to recreate the key. each client pair can do an individual agreement or the entire group can via exchanging public keys.
  - oconnor663 6y ago
    If you already have pairwise E2E encryption working, you can use it to distribute a shared key. It's the first part that's hard.
  - hunter2_ 6y ago
    If your video was encrypted once and multicast to all n other participants, couldn't you do it in such a way that it would be decryptable by n different keys that you handed out, one per participant, without anyone knowing other people's decryption keys? There will be n^2 keys total, but only n streams total. What would be an attack scenario here that wouldn't exist with the entirely infeasible n^2 streams scenario you mentioned? Nobody would be able to use the keys they possess to make an imposter stream.
- devit 6y ago
  What matters is that the server or software provided and anyone not in the group can't obtain plaintext even if they can intercept and modify all traffic on the Internet. Obviously you need to rotate the session keys when someone leaves, since they must no longer be able to obtain plaintext.
- ccktlmazeltov 6y ago
  > Is it sufficient to have a single key shared by all "ends" for the room, or must each user have its own key? It is enough that a single key is shared, that being said some systems do more because they want to provide additional properties to end-to-end encryption for groups.
- ghostpepper 6y ago
  Signal has published some interesting material addressing this question. https://signal.org/blog/signal-private-group-system/ https://signal.org/blog/signal-private-group-system/
blendergeek 6y ago
This is a dupe of https://news.ycombinator.com/item?id=22855407 https://news.ycombinator.com/item?id=22855407 The URL is slightly different but it is the same.
ccktlmazeltov 6y ago
> From this key we derive a 128bit key using PBKDF2. We use the room name as a salt in this key generation. This is a bit weak but we need to start with information that is the same for all participants so we can not yet use a proper random salt. 1) You do not need to use a password-based KDF if your key is a random bytearray of >= 16 bytes. I expect that most people would use their feature by copy/pasting the key in email or whatever channels they're using to communicate the room link. 2) I'm not sure about IV generation, maybe somebody with more knowledge on SSRC/etc. can look at that 3) decryption error do not kill the connection, that's untypical but I think that should be fine
- phoe-krk 6y ago
  > 3) decryption error do not kill the connection, that's untypical but I think that should be fine I assume that this is so you can deal with the fact that some individual frames have been lost and/or corrupted as long as the next ones decrypt just fine. That is important for video streams; I can imagine that the quality of life of people using E2EE streams would suffer if the stream was highly vulnerable to corrupting even a single bit within any of the frames.
  - ccktlmazeltov 6y ago
    In practice a bunch of layers under the application one have checksums: UDP already has a checksum, IP already has a checksum too, the data link layer too... so maybe you wouldn't even reach a naturally corrupted AES-GCM ciphertext? Not sure what are the probabilities for the UDP checksum though.
john37386 6y ago
Shouldn't they inspire the end to end encryption from openSSH. As far as I know it's used by many worldwide and it seems fairly secure. Maybe I am missing something though.
- ffk 6y ago
  It looks like what they have now is openssh like. Client 1 sends data to the server encrypted. Server decrypts. Server reencrypts and sends to client 2. This describes how to communicate in such a way where the client 1 and 2 can communicate with the server in the data path and The server being unable to see the contents of the message. The hard part is key management between clients in a secure way.
  - edoceo 6y ago
    You said "server decrypts" but then also "server being unable to see contents". How? If I decrypt, I see contents.
    - ffk 6y ago
      I was unclear in my comment. I was describing a before and after set of solutions. The former allows for server side decryption. The latter approach would prevent server side decryption.
      - edoceo 6y ago
        Now I get it, thx
    - SparkyMcUnicorn 6y ago
      I think he's wrong. The server never receives the key. The bridge passes along the encrypted stream and encryption/decryption only happens client side. In the demos, you can see that the parameter is a # parameter and not a query parameter.
- chupasaurus 6y ago
jdc 6y ago
In short: * currently the Jitsi Meet videobridge sees unencrypted conversations * they're changing that using a new WebRTC API called "Insertable Streams" * it's currently in alpha with an open RFC * they plan to use the double ratchet algorithm for key exchange in the future
- tialaramex 6y ago
  The mention of double ratchet is confusing and maybe worrying in the sense that it feels as though they don't understand what they're doing here. The Double Ratchet is designed around synchronous linear messages: Alice: "Hi Bob" Bob: "Hey" Alice: "Check out our new house guest!" <cat photo> Bob: "Aww :cat-emoji: :heart:" One of the two ratchets changes the key used for messages from Alice to Bob each time Alice sends a message, ensuring that knowing one of these ephemeral keys only gets you one message and resetting all the assumptions about how much data can safely be encrypted with a single key. And of course likewise from Bob to Alice. The other ratchet uses the a Diffie-Hellman style algorithm to agree new keys entirely each time they exchange messages back and forth, in order to repair key compromise. But, while this makes sense for an application that is periodically sending messages it isn't a reasonable fit for video streaming. It doesn't make sense to change the keys for each frame transmitted for example. I guess it can make sense to have the system automatically change the keys when participants leave, somehow, as this means a participant can't secretly eavesdrop calls they seem to have left. But I don't see how that's the double ratchet. Their example 'foo' password obviously is a placeholder, and I can see that if they used a scheme like Jitsi's default random VC names ("BearsMasticateSteakImmediately") you could have something that can't reasonably be brute-forced but exactly what happens with key exchange definitely needs more thought. The good news is that done correctly that's largely orthogonal to the encryption problem. It's important, but it doesn't need to block the other work.
  - OrgNet 6y ago
    > It doesn't make sense to change the keys for each frame transmitted for example. If it doesn't hurt the reliability of the communication, I don't see the problem... and it could have "hidden" benefits.
the100rabh 6y ago
So right now its chrome only ?
sandov 6y ago
Tangential (and noob) question: Could there be an encryption+compression scheme where: 1. Sender sends an encrypted stream at K bps. 2. Server takes the encrypted stream and compresses it, without decrypting anything. It then sends encrypted+compressed stream at J bps (J<K) to end recipient. 3. The end recipient decrypts the compressed stream using a key provided by the original sender, not the server. This with reasonably secure encryption and reasonably size-efficient codecs, obviously. So the step 2 would add compression additional to the compression of the original codec. Is this mathematically possible?
- pronoiac 6y ago
  You can't compress properly encrypted data.
- jstanley 6y ago
  If the data is encrypted well, it should be indistinguishable from random noise. You can't compress random noise. Ergo, you can't compress encrypted data. It's a nice idea though.
- deleted 6y ago
  [deleted]
- abdullahkhalids 6y ago
  Naively no, but I wonder if there is some variant of homomorphic encryption that does this? I would be surprised though if this was efficiently possible.
  - sandov 6y ago
    Yes, I think homomorphic encryption is what I was thinking about, although I didn't know its name until now.
- ww520 6y ago
  Usually you compress first then encrypt. Unencrypted data has better compression ratio. Also modern video data is already compressed where most frames are difference data.
Snelius 6y ago
Too early, jitsi needs lot of work to get good basic features first. Their "videobridge" just a pieces of software without docs, arch description, has not possibility to run as pure SFU without any other jitsi parts like Colibry XMPP. And etc. "InsertableStreams" scheduled for Chrome only and future 84 version, still experimental and if it's a after codec processing then useless.
- VWWHFSfQ 6y ago
  Janus [1] is a much more capable webrtc gateway that's pluggable to do anything you want. Jitsi is like a Wowza type server. Stay away. [1] https://github.com/meetecho/janus-gateway https://github.com/meetecho/janus-gateway
  - jfim 6y ago
    Is it a turnkey solution? Janus seems more like a WebRTC gateway with no directly usable end-user app (eg. video chat). Jitsi Meet seems to be a turnkey thing where you can just self host an instance and have users create video meetings without too much fuss.
    - gfodor 6y ago
      This might be useful: https://www.youtube.com/watch?v=u8ymYTdA0ko https://www.youtube.com/watch?v=u8ymYTdA0ko Janus is more of a Swiss Army knife, vs a all-in-one app for a specific use case for webrtc.
  - Snelius 6y ago
    Ye will see, thx. I'm looking the "mediasoup" SFU, it looks very nice, but need to try a code.
m3kw9 6y ago
As if Zoom or any pro company doesn’t actually know. Bragging about knowing what it means actually make them sound amateurish.
- VWWHFSfQ 6y ago
  Zoom has fundamental problems that makes them not able to support E2E easily. They only recently started sending video over WebRTC data channels. Before they were sending over websockets. They're not even using the browser's native media streaming APIs. So E2E is a huge problem for them to implement.
rixtox 6y ago
I want to point out that E2E encryption on Web doesn't make your conversation more secure than regular HTTPS encryption without E2E encryption. The core to the argument here is the threat model. The whole point of using E2E on any conversation is to make sure that even the service provider cannot read your conversation. It's very clear that the threat model is againsting the service provider. However, the very same service provider of your conversation channel also provides the underlying encryption application on Web. That means, if the service provider wants to act evil, it's always possible to sneak you an application that steals your conversation by simply not applying E2E encryption, or just eavesdropping before encrypting. The root of the problem is that Web application doesn't have a root of trust. As long as this problem is not addressed, E2E encryption on Web will always be meaningless.
- jandrese 6y ago
  This kind of thinking is why PGP never took off. Yes, your ISP could hack the binaries, break the HTTPS trust model somehow, and alter what you download, but practically speaking that isn't going to happen. Trying to build your system to defeat an adversary who has that kind of power ends up making it too cumbersome for the 99.999% use case. What I don't understand is why the server needs to decrypt the traffic at all. Why not just have it rebroadcast the encrypted streams? The endpoints could exchange crypto keys with public key crypto and to the video server it would just be a bunch of bytes. Clients would turn on and off video streams from different clients based on network conditions and how much screen real-estate they have. Audio could even be encoded on a different channel so it could always be forwarded even if the video is not.
  - ComodoHacker 6y ago
    >What I don't understand is why the server needs to decrypt the traffic at all In short, to make it scale for many (tens to hundreds) participants. Clever techniques like Simulcast[0] and SVC[1] allow that, but routing server must support it to meet different requirements of individual participants. 0. https://webrtchacks.com/sfu-simulcast/ https://webrtchacks.com/sfu-simulcast/ 1. https://webrtchacks.com/chrome-vp9-svc/ https://webrtchacks.com/chrome-vp9-svc/

245 points by lopespm 6y ago

I have a question on the definition of "end-to-end encryption" with regards to groups/rooms. Is it sufficient to have a single key shared by all "ends" for the room, or must each user have its own key? If a single group key is acceptable, must it be rotated as a member goes or comes? I'm just looking for common definition of the term wrt webrtc groups for fear of misusing it when describing a product. (for the purposes of this clarification, pretend I have key distribution/derivation figured out and I whether I use asymm or symm encryption doesn't apply to the question itself)

otachack 6y ago
I think it's a hot topic and the definition is divisive. Having 1 "secret" that end users share and use is technically end to end encryption, I'd say, but it's kind of like sending messages to yourself. It's kind of like setting up one private/public key pair, then sharing both with everyone in your group and writing each other messages with them. If one of your group become a malicious actor, or if a malicious actor manages to steal the pair, it can compromise the group communications. You also can't cryptographically distinguish between each other since you share one identity. Mix in video conferencing, though, and you really just have to trust what you see/hear from your peers video feed in addition to trusting your shared key pair isn't compromised. Ideally, each party member has their unique key pair, they share their public keys between the group, then communicate that way. But you got more overhead in starting a Jitsi meet room rather than just a link and a shared password.
- warkdarrior 6y ago
  Separate keys means you need to have separately encrypted streams for each pair of participants. This is probably not scalable, and definitely does not play well with multicast or with a video-routing server.
  - notduncansmith 6y ago
    I think a strong cryptographic communications platform would offer the option of using either multi-party-shared-key or p2p key pairs depending on the use-case. Similar to how Slack has both private and public channels within an org.
  - the8472 6y ago
    Not really. You can have internal per-packet keys which you throw away after your cryptographic setup and then only convey that key in separately in some encrypted form to each member along with a common payload which is amenable to multicast. I think that's a piece of signal's group chat protocol.
  - adrianmonk 6y ago
    Is that really true? I'm not a cryptographer by any means, but it seems like every time you transmit a chunk of video over the network, you could generate a single-use key, encrypt the video with that key, and then encrypt the single-use key with every intended recipient's individual key. When the recipients get the message, they'd find their encrypted copy of the temporary key in the list, recover the single-use key, then decrypt the video. That way the only wasted bandwidth is in transmitting keys, which is a lot smaller than video. The recipients could give the single-use key (that they decrypted with their individual key) to someone who isn't supposed to have it, but that doesn't seem like a problem since they already have the decrypted data and could give that away. For a small performance improvement, you could re-use the temporary key a few times (for, say, 10 seconds) if the set of intended recipients doesn't change.
    - 0xBeefFed 6y ago
      I am not sure if this relates, but this past year at Blackhat there was a talk on Messaging Layer Security and they broughtup a concept called TreeKEM, where users share keys in a tree heirachy to reduce the number of shared secrets. Again, not sure if this is applicable, but the comments made me think of this. [0] https://www.blackhat.com/us-19/briefings/schedule/index.html#messaging-layer-security-towards-a-new-era-of-secure-group-messaging-16230 https://www.blackhat.com/us-19/briefings/schedule/index.html... [1] https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messaging-Layer-Security-Towards-A-New-Era-Of-Secure-Group-Messaging.pdf https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messagi...
crazygringo 6y ago
I think it's very much a gray area. True E2EE seems like each endpoint would have to have its own key. But the bandwidth realities of group videoconferencing make it entirely infeasible for each participant to be sending a separately encrypted stream to each other participant. So the only realistic solution is for all members to share the same key, which makes everything dependent on the security of the key distribution. But then... is it really E2EE? I'm not sure there's a generally accepted answer here.
- sarakayakomzin 6y ago
  > So the only realistic solution is for all members to share the same key, which makes everything dependent on the security of the key distribution. But then... is it really E2EE? each member deriving their own key and coming to an agreement on the client side is e2ee; it's primarily about the server not having knowledge or being able to recreate the key. each client pair can do an individual agreement or the entire group can via exchanging public keys.
- oconnor663 6y ago
  If you already have pairwise E2E encryption working, you can use it to distribute a shared key. It's the first part that's hard.
- hunter2_ 6y ago
  If your video was encrypted once and multicast to all n other participants, couldn't you do it in such a way that it would be decryptable by n different keys that you handed out, one per participant, without anyone knowing other people's decryption keys? There will be n^2 keys total, but only n streams total. What would be an attack scenario here that wouldn't exist with the entirely infeasible n^2 streams scenario you mentioned? Nobody would be able to use the keys they possess to make an imposter stream.
devit 6y ago
What matters is that the server or software provided and anyone not in the group can't obtain plaintext even if they can intercept and modify all traffic on the Internet. Obviously you need to rotate the session keys when someone leaves, since they must no longer be able to obtain plaintext.
ccktlmazeltov 6y ago
> Is it sufficient to have a single key shared by all "ends" for the room, or must each user have its own key? It is enough that a single key is shared, that being said some systems do more because they want to provide additional properties to end-to-end encryption for groups.
ghostpepper 6y ago
Signal has published some interesting material addressing this question. https://signal.org/blog/signal-private-group-system/ https://signal.org/blog/signal-private-group-system/

blendergeek 6y ago

This is a dupe of https://news.ycombinator.com/item?id=22855407 https://news.ycombinator.com/item?id=22855407 The URL is slightly different but it is the same.

ccktlmazeltov 6y ago

> From this key we derive a 128bit key using PBKDF2. We use the room name as a salt in this key generation. This is a bit weak but we need to start with information that is the same for all participants so we can not yet use a proper random salt. 1) You do not need to use a password-based KDF if your key is a random bytearray of >= 16 bytes. I expect that most people would use their feature by copy/pasting the key in email or whatever channels they're using to communicate the room link. 2) I'm not sure about IV generation, maybe somebody with more knowledge on SSRC/etc. can look at that 3) decryption error do not kill the connection, that's untypical but I think that should be fine

phoe-krk 6y ago
> 3) decryption error do not kill the connection, that's untypical but I think that should be fine I assume that this is so you can deal with the fact that some individual frames have been lost and/or corrupted as long as the next ones decrypt just fine. That is important for video streams; I can imagine that the quality of life of people using E2EE streams would suffer if the stream was highly vulnerable to corrupting even a single bit within any of the frames.
- ccktlmazeltov 6y ago
  In practice a bunch of layers under the application one have checksums: UDP already has a checksum, IP already has a checksum too, the data link layer too... so maybe you wouldn't even reach a naturally corrupted AES-GCM ciphertext? Not sure what are the probabilities for the UDP checksum though.

john37386 6y ago

Shouldn't they inspire the end to end encryption from openSSH. As far as I know it's used by many worldwide and it seems fairly secure. Maybe I am missing something though.

ffk 6y ago
It looks like what they have now is openssh like. Client 1 sends data to the server encrypted. Server decrypts. Server reencrypts and sends to client 2. This describes how to communicate in such a way where the client 1 and 2 can communicate with the server in the data path and The server being unable to see the contents of the message. The hard part is key management between clients in a secure way.
- edoceo 6y ago
  You said "server decrypts" but then also "server being unable to see contents". How? If I decrypt, I see contents.
  - ffk 6y ago
    I was unclear in my comment. I was describing a before and after set of solutions. The former allows for server side decryption. The latter approach would prevent server side decryption.
    - edoceo 6y ago
      Now I get it, thx
  - SparkyMcUnicorn 6y ago
    I think he's wrong. The server never receives the key. The bridge passes along the encrypted stream and encryption/decryption only happens client side. In the demos, you can see that the parameter is a # parameter and not a query parameter.
chupasaurus 6y ago

jdc 6y ago

In short: * currently the Jitsi Meet videobridge sees unencrypted conversations * they're changing that using a new WebRTC API called "Insertable Streams" * it's currently in alpha with an open RFC * they plan to use the double ratchet algorithm for key exchange in the future

tialaramex 6y ago
The mention of double ratchet is confusing and maybe worrying in the sense that it feels as though they don't understand what they're doing here. The Double Ratchet is designed around synchronous linear messages: Alice: "Hi Bob" Bob: "Hey" Alice: "Check out our new house guest!" <cat photo> Bob: "Aww :cat-emoji: :heart:" One of the two ratchets changes the key used for messages from Alice to Bob each time Alice sends a message, ensuring that knowing one of these ephemeral keys only gets you one message and resetting all the assumptions about how much data can safely be encrypted with a single key. And of course likewise from Bob to Alice. The other ratchet uses the a Diffie-Hellman style algorithm to agree new keys entirely each time they exchange messages back and forth, in order to repair key compromise. But, while this makes sense for an application that is periodically sending messages it isn't a reasonable fit for video streaming. It doesn't make sense to change the keys for each frame transmitted for example. I guess it can make sense to have the system automatically change the keys when participants leave, somehow, as this means a participant can't secretly eavesdrop calls they seem to have left. But I don't see how that's the double ratchet. Their example 'foo' password obviously is a placeholder, and I can see that if they used a scheme like Jitsi's default random VC names ("BearsMasticateSteakImmediately") you could have something that can't reasonably be brute-forced but exactly what happens with key exchange definitely needs more thought. The good news is that done correctly that's largely orthogonal to the encryption problem. It's important, but it doesn't need to block the other work.
- OrgNet 6y ago
  > It doesn't make sense to change the keys for each frame transmitted for example. If it doesn't hurt the reliability of the communication, I don't see the problem... and it could have "hidden" benefits.

the100rabh 6y ago

So right now its chrome only ?

sandov 6y ago

Tangential (and noob) question: Could there be an encryption+compression scheme where: 1. Sender sends an encrypted stream at K bps. 2. Server takes the encrypted stream and compresses it, without decrypting anything. It then sends encrypted+compressed stream at J bps (J<K) to end recipient. 3. The end recipient decrypts the compressed stream using a key provided by the original sender, not the server. This with reasonably secure encryption and reasonably size-efficient codecs, obviously. So the step 2 would add compression additional to the compression of the original codec. Is this mathematically possible?

pronoiac 6y ago
You can't compress properly encrypted data.
jstanley 6y ago
If the data is encrypted well, it should be indistinguishable from random noise. You can't compress random noise. Ergo, you can't compress encrypted data. It's a nice idea though.
deleted 6y ago
[deleted]
abdullahkhalids 6y ago
Naively no, but I wonder if there is some variant of homomorphic encryption that does this? I would be surprised though if this was efficiently possible.
- sandov 6y ago
  Yes, I think homomorphic encryption is what I was thinking about, although I didn't know its name until now.
ww520 6y ago
Usually you compress first then encrypt. Unencrypted data has better compression ratio. Also modern video data is already compressed where most frames are difference data.

Snelius 6y ago

Too early, jitsi needs lot of work to get good basic features first. Their "videobridge" just a pieces of software without docs, arch description, has not possibility to run as pure SFU without any other jitsi parts like Colibry XMPP. And etc. "InsertableStreams" scheduled for Chrome only and future 84 version, still experimental and if it's a after codec processing then useless.

VWWHFSfQ 6y ago
Janus [1] is a much more capable webrtc gateway that's pluggable to do anything you want. Jitsi is like a Wowza type server. Stay away. [1] https://github.com/meetecho/janus-gateway https://github.com/meetecho/janus-gateway
- jfim 6y ago
  Is it a turnkey solution? Janus seems more like a WebRTC gateway with no directly usable end-user app (eg. video chat). Jitsi Meet seems to be a turnkey thing where you can just self host an instance and have users create video meetings without too much fuss.
  - gfodor 6y ago
    This might be useful: https://www.youtube.com/watch?v=u8ymYTdA0ko https://www.youtube.com/watch?v=u8ymYTdA0ko Janus is more of a Swiss Army knife, vs a all-in-one app for a specific use case for webrtc.
- Snelius 6y ago
  Ye will see, thx. I'm looking the "mediasoup" SFU, it looks very nice, but need to try a code.

m3kw9 6y ago

As if Zoom or any pro company doesn’t actually know. Bragging about knowing what it means actually make them sound amateurish.

VWWHFSfQ 6y ago
Zoom has fundamental problems that makes them not able to support E2E easily. They only recently started sending video over WebRTC data channels. Before they were sending over websockets. They're not even using the browser's native media streaming APIs. So E2E is a huge problem for them to implement.

rixtox 6y ago

I want to point out that E2E encryption on Web doesn't make your conversation more secure than regular HTTPS encryption without E2E encryption. The core to the argument here is the threat model. The whole point of using E2E on any conversation is to make sure that even the service provider cannot read your conversation. It's very clear that the threat model is againsting the service provider. However, the very same service provider of your conversation channel also provides the underlying encryption application on Web. That means, if the service provider wants to act evil, it's always possible to sneak you an application that steals your conversation by simply not applying E2E encryption, or just eavesdropping before encrypting. The root of the problem is that Web application doesn't have a root of trust. As long as this problem is not addressed, E2E encryption on Web will always be meaningless.

jandrese 6y ago
This kind of thinking is why PGP never took off. Yes, your ISP could hack the binaries, break the HTTPS trust model somehow, and alter what you download, but practically speaking that isn't going to happen. Trying to build your system to defeat an adversary who has that kind of power ends up making it too cumbersome for the 99.999% use case. What I don't understand is why the server needs to decrypt the traffic at all. Why not just have it rebroadcast the encrypted streams? The endpoints could exchange crypto keys with public key crypto and to the video server it would just be a bunch of bytes. Clients would turn on and off video streams from different clients based on network conditions and how much screen real-estate they have. Audio could even be encoded on a different channel so it could always be forwarded even if the video is not.
- ComodoHacker 6y ago
  >What I don't understand is why the server needs to decrypt the traffic at all In short, to make it scale for many (tens to hundreds) participants. Clever techniques like Simulcast[0] and SVC[1] allow that, but routing server must support it to meet different requirements of individual participants. 0. https://webrtchacks.com/sfu-simulcast/ https://webrtchacks.com/sfu-simulcast/ 1. https://webrtchacks.com/chrome-vp9-svc/ https://webrtchacks.com/chrome-vp9-svc/