Re: [GNUnet-developers] Chat System, again

[Arne Wichmann]

begin  quotation  from Christian Grothoff (in <address@hidden>):
> On Tuesday 28 September 2004 14:48, Arne Wichmann wrote:
> > begin  quotation  from Christian Grothoff (in 
> <address@hidden>):
> > > Sorry for the late reply.  There is no active work on it at this point.
> > > Nevertheless, there have been various ideas that I've been discussing
> > > with people in terms of how it should be implemented.  So you should feel
> > > free to give people such a project, but if you want to increase your
> > > chances that it'll eventually end up in the main codebase you might want
> > > to give me a chance at the description you're handing out (it might also
> > > be useful anyway since I might be able to point out some general problems
> > > / ideas in terms of how to use GNUnet 'properly').
> >
> > begin  quotation  from Marcos D. Marado Torres (in 
> <address@hidden>):
> > > On Thu, 2 Sep 2004, Arne Wichmann wrote:
> > > > Is there anyone actively working on a more elaborated chat system for
> > > > Gnunet at the moment? I am just thinking to give out a practicum which
> > > > would be a start of such a thing.
> 
> > Ok, to start that up: I sent the following to my supervisor (short and
> > rough translation of a german text):
> >
> > SEP: chat system for Gnunet
> >
> > Gnunet is an anonumous p2p-protocol, which supplies an anonymizing
> > transport layer for applications based on it. Gnunet already implements a
> > file sharing protocol.
> 
> Well, the transport layer provides some functionality helpful for 
> anonymization (notably link encryption, batching, delaying, constant-size 
> messages, relatively constant traffic due to message scheduling), but that is 
> not necessarily sufficient to obtain anonymity.  An anonymous routing 
> protocol is still required.

Ok, that was a bit unprecise. I suppose (as Marcos seems to) that the
anonymizing part of the Filesharing system could be reused for it.

> > The big scope of the task is, to create an anonymizing chat system based on
> > the Gnunet network. In this SEP in a first step the protocol shall be
> > created and a limited prototype be implemented.
> >
> > Users of the systems shall (optionally) have unique names, which
> > nevertheless shall be hard to retrace to an actual person.
> 
> I would use / recycle the existing pseudonym construct in GNUnet: the hash of 
> your public key is your unique pseudonym; you can choose a nickname and sign 
> it to get a more user-friendly handle, but if two nicks conflict the public 
> key is the ultimate unique handle.  Anything else is unlikely to work in a 
> distributed setting anyway.

Hm. On first glance this seems to be tied to the machine a person is
sitting at. This would be inconvenient, persons tend to be changing
machines now and then. And such a concept should be movable. Which may mean
to transfer a hash file from one machine to another, but it still should be
movable.

> > Users shall be able to assemble in channels for group conversation. One to
> > one conversation shall be possible too.
> 
> So suppose we have channels that are identified by some name (or hash of some 
> name?).  How do you (or can you) prevent listening of users on the channel 
> that are not listed as participants (users that run some peer in the network 
> that routes traffic of the channel should still not be able to listen in 
> without being visible to the other users, right?  That means re-keying for 
> every join/leave, which introduces a big DoS problem (rapid join/leave)).  Do 
> you want to be able to ban users from participating in a channel (operator 
> status?).  How would that be implemented?  Do we want open channels (anyone 
> can join) or should we for security require 'invite only' channels?

I did not really think that through yet. At the minimum a channel could be
a reflector hosted on a machine. This would have some security problems,
but it would work. But your scetch surely leads to a better solution. Let
me think about it.

The DoS problem of rekeying would be less severe if the rekeying is done
with a lower priority than the messages, and old keys are used until new
keys are announced as being available.

I will brood a bit upon that.

> > The infrastructure of Gnunet shall be used to hide souces (and
> > destinations) of chat traffic.
> 
> GNUnet can do discovery and hopefully soon provide a DHT, but that does not 
> provide you with a chat-specific anonymizing routing algorithm. Also, what 
> are your reliability and latency goals?  Total message ordering?  3-way 
> end-to-end handshake with all participants, one peer responsible for routing 
> (and in a position where that peer could selectively drop messages and no one 
> would know)?  What delays between messages are acceptable?

Latency requirements of a line-based chat systems are not so bad. Irc still
works ok with latencies of about 10 seconds. More might still be doable.

Reliability is desirable, and I know that this is not so trivial.

There are some rough ordering requirements, such as answers should come
after questions, but no total message ordering.

One peer responsible for routing is what i proposed above and am not very
happy with.

What is the question about delays?

[...]
> > Still it would be interesting to hear your ideas. ;) It would reduce the
> > need to have good ones of my own. :-}
> 
> Well, ok, I didn't give as much as ideas for solutions but rather problems 
> that you may (or may not) want to try to solve :-).  Keep me posted...

Sure. ;)

begin  quotation  from Marcos D. Marado Torres (in <address@hidden>):
> On Tue, 28 Sep 2004, Christian Grothoff wrote:
> 
> > Well, the transport layer provides some functionality helpful for
> > anonymization (notably link encryption, batching, delaying, constant-size
> > messages, relatively constant traffic due to message scheduling), but that 
> > is
> > not necessarily sufficient to obtain anonymity.  An anonymous routing
> > protocol is still required.
> 
> Can't SEP use the routing protocol that the file-sharing system uses?

Oops. SEP is just the name of the type of project that this should be. ;)

I did not give the protocol a name.

[reformatted]
> > I would use / recycle the existing pseudonym construct in GNUnet: the
> > hash of your public key is your unique pseudonym; you can choose a
> > nickname and sign it to get a more user-friendly handle, but if two
> > nicks conflict the public key is the ultimate unique handle.  Anything
> > else is unlikely to work in a distributed setting anyway.

> My idea in this field was to use the hash as the "real nickname" and
> relate a "chosen nickname" to it. Everytime someone new enters SEP, a
> database in each client connected at the time is updated, and if there is
> some other different hash with that nickname, then a request to change
> nickname must be sent. On the other side, the guy who finds that there is
> already another person with that nickname may have the ability to, in his
> client, change the nickname that will appear in messages from that hash.
> This doesn't warrant against repeated nicknames, but will prevent people
> to think they're talking to someone when in fact they aren't.

Hm. I would try with non-unique Handles, like most IMs do. And have a
global naming scheme above that (like irc-nicks or ICQ-UINs).

> > So suppose we have channels that are identified by some name (or hash
> > of some name?).  How do you (or can you) prevent listening of users on
> > the channel that are not listed as participants (users that run some
> > peer in the network that routes traffic of the channel should still not
> > be able to listen in without being visible to the other users, right?
> > That means re-keying for every join/leave, which introduces a big DoS
> > problem (rapid join/leave)).  Do you want to be able to ban users from
> > participating in a channel (operator status?).  How would that be
> > implemented?  Do we want open channels (anyone can join) or should we
> > for security require 'invite only' channels?

> There must be the abillity to create public or private rooms. Room names

Hm. I would not use different room types. I would rather distinguish
"published" and "non-published" rooms.

> must be unique. The creator of a room is it's owner (maybe we can add a

Yes (unique).

> feature that lets "give" the ownership of a room to another person).

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.

cu

AW
-- 
<ThePhonk> *tueteKlammernUeberVariableAuskipp* Dereferenzier Dich, Du
+Miststueck!

signature.asc
Description: Digital signature