Re: [GNUnet-developers] Chat System, again

[Christian Grothoff]

On Sunday 03 October 2004 04:58, Niklas Höglund wrote:
> 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.

Ok, first, I would highly recommend using the session key, since using say 
2048-bit RSA will make all of your messages 256 bytes long (even if you just 
type "Hi").  With a session key, you just have the overhead of the headers, 
(which you have anyway), so your messages will be much much smaller, and 
bandwidth does matter -- especially if you intend to send a message to each 
participant (which is probably ok as long as you have only a few 
participants).  

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

The problem is that if you have one big chat room with 1000 participants I'm 
not sure how well that would go :-).  At this point the pure RSA solution 
will deteriorate terribly (even in terms of CPU if you use long keys), and 
with the all-to-all routing you'll get to a point where you'll need lots of 
bandwidth.  But of course otherwise this scheme probably is quite resistant 
to attacks and highly decentralized.

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

Would that mean that I could fake the message ordering by just putting 
different (older) hash tokens into the stream?

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

Right, but what exactly does a peer do if it detects this? Sure, one could try 
to obtain the message from another participant. The problem is, that I may 
intentionally not send you a message X (but everyone else), your client stops 
showing messages for a while (waiting for X), then detects that X is missing 
(with some extra latency), then recovers X from another peer (after even more 
time), and then displays all messages that had to be shown after X.  That 
would allow me to make your client look rather erratic (think of getting 20 
messages in a block, then a 30s pause, then another 20 messages in a block). 
Ok, this might just be annoying (and since the offending message X would 
always be the first in the block you may just decide to /ban the bad guy -- 
but how can we be sure that he's a bad guy and that there is not just some 
networking problem preventing him from sending you the message in time???).

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

TCP/IP is not that simple anymore, since you're likely to have peers behind 
NAT boxes and other obstacles.  The new RPC code (at best alpha-quality, I'm 
still debugging) gives you reliable communication between two neighbors, but 
global routing that would allow you to do reliable any-to-any communication 
is not yet implemented (and would again raise questions about how you do it 
anonymously).

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

Right, that would pretty much only require reading in an existing GPG key and 
making up a GNUnet pseudonym from it by signing the GNUnet pseudonym with 
your GPG key.  That's a simple extension that could be added at the end.

C