Group chats generally don’t have E2EE. Most apps provide that only for one-to-one conversations. Group E2E encryption is a difficult problem.
The kid was using airport wifi for this right? I'd guess public airport wifi installs some backdoored SSL cert and is generally monitored (and you probably agree to this ToS when you use it) - you may even agree to not make jokes about planes - I wouldn't be surprised.
I've implemented E2EE in group chats using Olm/Megolm and it's not easy to scale and comes with a ton of limitations.
If I was running Snapchat, I wouldn't see the point in dedicating that many resources and infrastructure to it.
Not if it was architected properly from the beginning.
It's an extremely flexible design and has relatively few constraints in how it can be used in a larger system, but it's just extremely new.
The ART construction exited a few years ealier than TreeKEM but that's a weaker design with more restrictions so it wasn't adopted very widely afaik.
What? We could do better than that before we had group chats. PGP will let you send encrypted email to multiple recipients, and multiple simultaneous bilateral encryption sessions are not involved.
The system is:
1. You encrypt the message using a symmetric encryption key.
2. You encrypt the key, which is short, once for every recipient.
3. You prepend the whole bundle of encrypted keys to the message.
4. You send that out. Everyone receives the same encrypted data. This is what would appear in a group channel.
5. When you receive a message, you try to decrypt it. If decrypting the header doesn't produce a key for you, then you're not one of the recipients.
Even if you want to analyze this as a set of bilateral sessions, the storage and computation requirements are linear, not quadratic: when I send a shared message to Alice and Bob, I need to know how I send messages to Alice, and I need to know how I send messages to Bob, but I don't care how Alice sends messages to Bob.
TreeKEM also manages sublinear communication, constant per message (since there's a shared secret already used for the ratchet) and logn for key updates or group membership changes.
> I was speaking of protocols that did have these properties.
The method PGP uses to encrypt messages to multiple recipients will still work for whatever protocol you have in mind. Why is your dislike for PGP relevant?
I don't dislike PGP I'm just saying that it doesn't natively have PFS and PCS, which are generally accepted by security people as being necessary properties for a protocol to be considered full E2EE.
But it's impossible for the authority to achieve that goal. If they manage the group membership, they are free to add themselves and read the discussions.