Hacker News new | past | comments | ask | show | jobs | submit login

Nah the best you could do for a long while was just to have n^2 bilateral encryption sessions that behave like a group channel. Only fairly recently was a workable construction for doing many-party encryption sessions actually developed, called TreeKEM, and is now standardized in the IETF MLS standard. This is literally bleeding edge cryptography.

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.




When talking about recent, you're talking about 6 years ago right?


Has it been 6 years already? I must be getting old.


> Nah the best you could do for a long while was just to have n^2 bilateral encryption sessions that behave like a group channel.

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.


PGP is poorly suited for live conversations with rotating members like this since it doesn't support post-compromise security or perfect forward secrecy (not in-protocol, at least), which most people would expect from an E2EE chat protocol. I was speaking of protocols that did have these properties.

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.


The concept of encryption is poorly suited for live conversations with rotating members. If you don't know who you're talking to, there's no point in encrypting your message.

> 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?


That's pretty reductive, perhaps you don't have a fully connected graph of relationships in a group but other parties you do know in a group you trust to vouch for others. There's also lots of data privacy/security compliance reasons you'd want to have E2EE with large groups. I believe I heard that some larger companies wanted to investigate using MLS to encrypt internal communications, and having hundreds/thousands of people in a group where most don't know each other but they're all managed by an authority who doesn't want to be able to know what they're discussing.

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.


> I believe I heard that some larger companies wanted to investigate using MLS to encrypt internal communications, and having hundreds/thousands of people in a group where most don't know each other but they're all managed by an authority who doesn't want to be able to know what they're discussing.

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.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: