5 ms·
I think you missed a solution, which is a variant of #2. To simplify things, consider a single global chat room, on an enormous server (probably in Salt Lake C
by javajosh 7y ago
I think you missed a solution, which is a variant of #2.
To simplify things, consider a single global chat room, on an enormous server (probably in Salt Lake City), where every person on earth is connected and have a public/private key-pair, and every person on Earth can read everything anyone posts. You can post publicly ( anonymously or with a signature), or privately (pair key) to any individual on Earth. From this starting point, how do you make private group chats? (This starting point factors out a lot things we shouldn't worry about, and I think is simpler/nicer than a story about a Slack admin).
Your solution #1, pairwise encryption, clearly doesn't scale for the sender (as you point out). It is also aesthetically displeasing.
I feel like your solution #2, though, isn't what I would do, and I'm honestly surprised that's how WhatsApp, etc. works.
My first thought is that a person who wants a shared room creates a (symmetric) key K for the room, and then distributes K to all invited participants privately. To remove a user you generate a new K for the room, and send it to N-1 participants. They all agree to post using the new K (and a signature).
I don't see a performance issue with this solution. Consider that every message to the "room" causes O(N) fanout. If the rate of "normal" message addition is much less than the rate of participant addition/subtraction, well, that's performant enough. (Especially considering a new key for the room is some relatively small fixed size.)
(In a situation where you have a huge, passive audience and a single emitter, then yes my proposal will generate a lot of extra unnecessary traffic as people enter or leave. However, I'd argue that communication like this is probably better secured through more traditional centrally controlled means, e.g. a server process with ordinary user accounts that have a connection status.)
EDIT: There is a coordination problem with my solution, in that you can't guarantee members will use the new K; it might be useful to have a bot or something remind anyone who posts using the old K to use the new one instead.
- thinkloop 7y agoI think the issue there is it would be an anonymous chat room - how would you know who sent the message?
- javajosh 7y agoGlad you asked. My solution allows for anonymous rooms, but "solution 2" does not. To be anonymous, just post ordinary text to the room using K. To be identified, post your text, your signature all encrypted with K.
- thinkloop 7y agoYes that's right. Normally for signatures you would do the final encryption with the receiver's public key creating the same issue as solution #1, but in this case you would use the symmetric key: 1. Hash message 2. Encrypt hash using your private key 3. Encrypt again using group's symmetric key There's obviously good reason why symmetric keys don't work, especially in place of solution #2 - would be great to be enlightened on why by the author.
- ajconway 7y agoTo distribute the new K you would need to encrypt it for each of the N-1 users of the group. That's why we need trees.
- javajosh 7y agoAh, thanks. My mistake was assuming you could distribute new K as a normal message, encrypted with old K. Clearly (now) this wont work since new K will be distributed to everyone, including people who need to be omitted.
- deleted 7y ago[deleted]
- doomrobo 7y agoThis is pretty close to another question in this thread. I think my answer applies to this as well https://news.ycombinator.com/item?id=20645717 https://news.ycombinator.com/item?id=20645717