4 ms·

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

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...
    - ccktlmazeltov 6y ago
      This still uses a single shared secret for the whole group.
      - 0xBeefFed 6y ago
        Thank you for verfiying that
        6y ago
- kodablah 6y ago
  I think it's fine if you don't re-encode (i.e. need to decode) the audio/video packets in any way. IIRC, you can broadcast RTP stream packets without knowing their contents if you settle on common codecs (e.g. opus and h264). But if you need to embed picture-loss-indicator messages or something, it might not work. I think this is the essence of "SFUs" (selective forwarding units) in WebRTC parlance.

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...
  - ccktlmazeltov 6y ago
    This still uses a single shared secret for the whole group.
    - 0xBeefFed 6y ago
      Thank you for verfiying that
      - 6y ago
kodablah 6y ago
I think it's fine if you don't re-encode (i.e. need to decode) the audio/video packets in any way. IIRC, you can broadcast RTP stream packets without knowing their contents if you settle on common codecs (e.g. opus and h264). But if you need to embed picture-loss-indicator messages or something, it might not work. I think this is the essence of "SFUs" (selective forwarding units) in WebRTC parlance.