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.

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.

"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.

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. :-)

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... [1] https://i.blackhat.com/USA-19/Wednesday/us-19-Robert-Messagi...

This still uses a single shared secret for the whole group.

Thank you for verfiying that

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).

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.

> some telegram rooms have tens of thousands of members

I'd say that at this point you can either:

* accept that there is no confidentiality anymore. It's just not realistic to have a "secret" group with that many members

* have the person who adds new members forward them the group key, and give up on key rotation

btw, I'm wondering how treeKEM manages malicious members when key rotation happens

> accept that there is no confidentiality anymore. It's just not realistic to have a "secret" group with that many members

You do have a point, especially when it's a group where people are in their free time. However, if they are present for work they are less likely to leak information. Also, encryption should give a default level of privacy to build on.

right, but how much do we want key rotation as a priority when a member leaves? What are the chances they're going to collude with whoever can see the traffic?