5 ms·

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

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 7y 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 7y 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 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
        7y ago
  - 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.
crazygringo 7y 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 7y 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 7y 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_ 7y 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 7y 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 7y 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 7y 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/

otachack 7y 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 7y 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 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
        7y ago
- 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.

crazygringo 7y 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 7y 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 7y 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_ 7y 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 7y 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 7y 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 7y 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/