Re: [GNUnet-developers] Chat System, again

[Niklas Höglund]

Friday 2004-10-01 20:34, Arne Wichmann wrote:
> I'm not so convinced about ownership. I thought a bit about operator
> status. There operators could be the entities which have the secret key to
> the room and can rekey it.
>
> > "tell's" (private messages) must be achievable between people in
> > different rooms. The owner must have the ability to turn the room public
> 
> Private messages I would do more or less independently from room
> communication. It does not need the overhead.
> 
> > or private, fixed or not fixed. People in a room (or owners of some room)
> > must have the ability to give or take invitations for that room. Room
> > owners must have the ability to "kick" someone from that room. And yes,
> > every join/leave in a certain room will create a DoS problem.
> 
> By rekeying operators could do most of these things. Invites could be done
> by giving out public keys.

If this is implemented by having a relaying server, as was suggested
somewhere in this thread, it would give the operators the right to
censure what is written, which I'd like to avoid.

I suggest this scheme instead:

Each user has an RSA keypair.

Joining a room is done by contacting one or more of its admins and
retrieving a list of users in the room.  Retrieving the same information
from more than one admin can be done to verify that a single admin isn't
lying to you.

Sending a message to a room is done by signing it, and then encrypting
and sending it to each person in the room.

Encrypting the message to all recipients using RSA might be costly, in
which case a session key could be agreed upon by each pair of users,
which could then be used to send the messages. I just tested the
encryption speed of the "ccrypt" command on my computer, and it could
encrypt 118 megs in 16 seconds, so encrypting a short message multiple
times with such an algorithm shouldn't be a problem.

I don't think the bandwidth of sending many messages would be too bad,
as chat messages are often quite short.

Each admin would "stream" a list of joins, leaves, kicks and bans to all
current users in the room. It would of course be possible for a user to
keep listening to a kicked user if he choose so.

To maintain message ordering, a message could contain the hash of the
most recent message seen when this message was written. All other users
know to place this message after that message.

One problem that I can see with this proposal is that users could send
messages to only some persons in a room. I'm not sure if this is bad.
This could be detected by adding a random selection of "(sender, msg
hash)" for recently seen messages to every sent message. That way, it
would be possible to detect missing messages.

I assume above that it is possible to implement an algorithm that sends
a message from one peer to another peer in a limited amount of time, and
guarantees that it reaches that peer.  Using TCP/IP, this should be
simple to implement, but using GNUnet and maintaining anonymity, this
may be difficult.

For "bonus points", the above could use GPG instead of simple RSA. This
way, the web of trust could be used. Anonymity could still be
maintained, if wanted, by using newly created anonymous keys.