3 ms·

I don't understand where this problem of distributing encryption keys comes from in the context of this tech demo. Zoom uses "passwords" and people are more tha

I don't understand where this problem of distributing encryption keys comes from in the context of this tech demo. Zoom uses "passwords" and people are more than happy to distribute them by email / WhatsApp / shouting from the rooftops. The important aspect is that the video conferencing provider and server do not know the key. I also disagree with your opinion that "you can't solve the UX on that". The tech demo here essentially gives the same UX as Zoom call + passwords, but with actual end-to-end encryption. There is the notable caveat in this tech demo that client-side scripts can still read the key (we have to assume the javascript that can read the URL hash is friendly). Really, though, this can be solved: provide a native(ish) app even if it's just an Electron wrapper of the existing static assets and javascript code, register a handler with the OS for `jitsi://`, and use links like `jitsi://server.name/room#e2ekey=foo`, so we only have to trust the code on our machine, not the server.

Arathorn 7y ago
I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.
- sigwinch28 7y ago
  Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript. I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.
  - cheald 7y ago
    I'm having trouble envisioning how you could possibly put together a solution where the encryption key wouldn't be visible to Javascript, malicious or otherwise. How would that work?
    - sigwinch28 7y ago
      Assuming that the client is essentially a web app then yes, the javascript must be able to read the encryption key. However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted. This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.

Arathorn 7y ago

I think passing in a static key (password) via a url fragment is what their demo is doing already. However, I get the impression the intention is to verify the keys of who's actually in the room, rather than just trusting a static key which will inevitably leak. They're presumably also planning to re-key via a ratchet to avoid a single leaked key compromising the whole conference recording.

sigwinch28 7y ago
Yes, my comment w.r.t. the hash is that it's inherently a bad final implementation because it's visible to the server via malicious Javascript. I really hope that it can be as simple as "share a password with someone"/"send an invite link to someone" because as the parent effectively said, this would be a complete UX nightmare.
- cheald 7y ago
  I'm having trouble envisioning how you could possibly put together a solution where the encryption key wouldn't be visible to Javascript, malicious or otherwise. How would that work?
  - sigwinch28 7y ago
    Assuming that the client is essentially a web app then yes, the javascript must be able to read the encryption key. However, it's not a hard requirement that the server delivers the javascript to us: it could be hosted locally, e.g. a trusted Electron wrapper around a set of HTML/CSS/JS stored on my computer, for some definition of trusted. This is how a lot of other e2e-encrypted messaging app can be used, e.g. Signal, WhatsApp, Riot.im: a "trusted" set of client code over which the untrusted server has no control.