4 ms·

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 wel

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 7y 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 7y 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 7y 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 7y 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 7y ago
    This still uses a single shared secret for the whole group.
    - 0xBeefFed 7y ago
      Thank you for verfiying that
      - ccktlmazeltov 7y ago
        To add to that, the only goal of TreeKEM is to avoid latency/complexity when adding and removing group member frequently/quickly. Which is really not the use-case of most groups (so not sure why they're doing this).
        est31 7y ago
        Probably groups with 6 or so members are alright, but the more people your group has, the more joining/parting there is. And the larger the effort is to distribute a new set of keys. So if you want your method to be scalable (and some telegram rooms have tens of thousands of members!), you need strategies like this.
        ccktlmazeltov 7y ago
- ccktlmazeltov 7y ago
  You both are right, what is not scalable is not encrypting messages to all when there are multiple keys, what is not scalable is sharing this shared secret and rotating it when members are added and removed frequently. This scalability issue is a non-problem imo: * I don't expect large group VCs, and I don't expect the member set to be updated frequently * For large group VCs, the threat model is much different and you can do broadcasting (use the same key) For group chat I would say that confidentiality goes out of the window when you start having a large group, so having one key is just more simple to implement and makes sense.
- hathawsh 7y ago
  I like that idea. I think there might be some risk that because all recipients receive the same encrypted text (encrypted by a different key for each recipient), a recipient may be able to discover other recipients' encryption keys. To avoid that, I think I would pad each encrypted text with random data, where each recipient gets different random data. Then the problem boils down to key management, but Keybase has that figured out IMHO. :-) It would be amazing to see a collaboration between Jitsi and Keybase to build end-to-end encrypted video chat with high quality crypto.
  - danenania 7y ago
    "I think there might be some risk that because all recipients receive the same encrypted text (encrypted by a different key for each recipient), a recipient may be able to discover other recipients' encryption keys." If that's possible, it means you're using horribly broken encryption. So it shouldn't be a concern if you're doing things right.
    - hathawsh 7y ago
      Yeah, on second thought, that would mean TLS is broken: if many people connect to a static web site and receive the same content, they would be at risk of revealing key material. However, they are not at risk of any such thing. Never mind. :-)
kodablah 7y 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.

notduncansmith 7y 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 7y 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 7y 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 7y 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 7y ago
  This still uses a single shared secret for the whole group.
  - 0xBeefFed 7y ago
    Thank you for verfiying that
    - ccktlmazeltov 7y ago
      To add to that, the only goal of TreeKEM is to avoid latency/complexity when adding and removing group member frequently/quickly. Which is really not the use-case of most groups (so not sure why they're doing this).
      - est31 7y ago
        Probably groups with 6 or so members are alright, but the more people your group has, the more joining/parting there is. And the larger the effort is to distribute a new set of keys. So if you want your method to be scalable (and some telegram rooms have tens of thousands of members!), you need strategies like this.
        ccktlmazeltov 7y ago
ccktlmazeltov 7y ago
You both are right, what is not scalable is not encrypting messages to all when there are multiple keys, what is not scalable is sharing this shared secret and rotating it when members are added and removed frequently. This scalability issue is a non-problem imo: * I don't expect large group VCs, and I don't expect the member set to be updated frequently * For large group VCs, the threat model is much different and you can do broadcasting (use the same key) For group chat I would say that confidentiality goes out of the window when you start having a large group, so having one key is just more simple to implement and makes sense.
hathawsh 7y ago
I like that idea. I think there might be some risk that because all recipients receive the same encrypted text (encrypted by a different key for each recipient), a recipient may be able to discover other recipients' encryption keys. To avoid that, I think I would pad each encrypted text with random data, where each recipient gets different random data. Then the problem boils down to key management, but Keybase has that figured out IMHO. :-) It would be amazing to see a collaboration between Jitsi and Keybase to build end-to-end encrypted video chat with high quality crypto.
- danenania 7y ago
  "I think there might be some risk that because all recipients receive the same encrypted text (encrypted by a different key for each recipient), a recipient may be able to discover other recipients' encryption keys." If that's possible, it means you're using horribly broken encryption. So it shouldn't be a concern if you're doing things right.
  - hathawsh 7y ago
    Yeah, on second thought, that would mean TLS is broken: if many people connect to a static web site and receive the same content, they would be at risk of revealing key material. However, they are not at risk of any such thing. Never mind. :-)

kodablah 7y 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.