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?