3 ms·

In short: * currently the Jitsi Meet videobridge sees unencrypted conversations * they're changing that using a new WebRTC API called "Insertable Streams" *

• 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.
    • vermilingua 6y ago
      It could also have “hidden” complications, which I find much more likely.
  • cvwright 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. I'll start this by saying that I recognize your username from lots of good informative posts here over the years. But I think you're being unnecessarily harsh here, to the point of taking maybe the most uncharitable interpretation of the limited data that we have. We've spent the past 20 years telling people not to roll their own crypto. Is it really that bad when somebody takes that advice to heart? > 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. They mentioned the Olm version of double ratchet. This usage scenario sounds a lot like ratcheting the sender keys in a Matrix group chat with Megolm. If you think that you might want to occasionally ratchet your keys (as speculated here [1]), then IMO it's better to grab something good (but possibly overpowered) off the shelf than to try to cobble together something yourself. Even if maybe you don't wind up using the hash-based ratchet very much. [1] https://news.ycombinator.com/item?id=22858476 https://news.ycombinator.com/item?id=22858476