[Standards-JIG] Many to many e2e encryption (JEP-116)

Nolan Eakins sneakin at semanticgap.com
Tue Nov 29 09:23:53 UTC 2005

Justin Karneges wrote:

>The trick, of course, is finding a way to distribute the session key, and it 
>would probably be a good idea to change it every time someone joins or leaves 
>(see SILC).  And then on top of that you need some sort of access control 
>over who can join the room (e.g. at the very least, it should require an 
>invite from an existing participant, or perhaps a password-protected room).
As Ralph pointed out, doing things like that means you trust the MUC 
service. I'd rather err on the side of not trusting the service with 
e2e. We need to answer the question of how long it'll take to encrypt N 
messages since this will be a security vs. speed tradeoff. Another thing 
is, if you're chatting with 100 people then you can either be running 
your own MUC service and/or you'll have greater breaches of security 
with the occupants themselves.

In the case where the party is running it's own MUC service, there would 
still be the issue of the occupants trusting their servers. I'm tempted 
to say that both approaches, each occupant handles encryption and the 
room handles encryption, might be optimal. In both cases the occupants 
need to communicate their keys. It would then be up to the occupants to 
decide if they trust the room or if they'd prefer creating a covert 
channel within the room.

For one to one and MUC, this could easily be done with presence by 
either sending the location of the key or the key itself. I'm not sure 
about pub/sub.

- Nolan

More information about the Standards mailing list