Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm guessing they want to set up a single session key, maintain deniability as well as authentication, and avoid leaks of the key when someone leaves the chat... It certainly seems that maintaining all of OTR's guarantees is a lot more difficult with more than one party involved.

With two parties, you either have a chat (both in conversation) or the session is ended (one or both parties leave).

If all you want is "traditional" encrypted chat alternatives might serve you better.

I'm not sure if I think re-using the OTR public keys/ids for encrypted chat that effectively isn't OTR (deniability, forward secrecy) is a good idea or not. Perhaps demand some form of indication from the user agent that clearly show group chat and individual chat is different?

As for "just broadcast multiple copies" -- that also depends on use-case. 100 person chat room? 10 person video conference? 10/100x bandwidth might not be the best approach.



Let's say Alice, Bob, Caesar and Dolores want to communicate. Couldn't Alice just open a 1 on 1 chat with Bob, then with Caesar, and then a third one with Dolores. And couldn't she then just copy and paste her message to all of them at the same time? And couldn't this be automated?


Yes, but then Caesar would have to trust Alice to relay Bob (which could be a fine and pragmatic solution for some use-cases, but wouldn't really be "otr-for-workgroups"). It would also suffer from poor network topology which could be a problem for large chats and/or high bandwith (and/or low latency) chats (file transfer, audio/video chat).




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

Search: