[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] Another bunch of ideas

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Another bunch of ideas
Date: Tue, 15 Jul 2003 04:40:47 +0200

Am Dienstag, 15. Juli 2003 01:12 schrieb Steven Barker:
> Well, as applied to AFS, I think a Confirmtion based keyword search
> could be done safely.  A Response that the searcher thinks was bogus
> would not be cached by the nodes that passed it along, however, it
> shouldn't be penalized by the node that already had it.  That node would
> simply decide behave as if it had never seen the request.  This means
> that unpopular data doesn't spread itself around the network unless some
> nodes invest the trust others have in them to request it and confirm it
> as good.  This makes spamming keywords much more dificult, as you will
> have to repeatedly request and confirm the spam data in order to keep it
> in the network.  Doing so abusively will lose you whatever trust you
> have from your neighbors, preventing you doing too much damage.

While I see nothing wrong with this argument, keeping the state around that 
can tell _where_ a response came from and that can route the confirmation 
back to the originator _after_ a potentially long delay (download time of the 
file, which, in network-time, maybe huge (a minute would be too long!)) is a 
real problem. Think of it this way. If your peer can track say 8.000 routes 
at a time (while maintaining reasonable memory bounds) and can route about 5 
replies and 100 queries per second (at 5 kbps!), how long can the user 
downloading the file take at most to send the confirmation?

Potentially worse, if we keep track of where the response came from, the FBI 
may knock on our door and require us to hand out that information.  While 
storing it for a few seconds maybe ok (note that it is currently discarded 
after trust levels are processed, which means you can count the delay for 
that in cycles), storing the routing information for longer times (minutes, 
hours) is also going to be(come) a security problem.

Thus I think it is just not implementable for practical reasons.  Besides, I 
think that with namespaces and directories, the probelm will be reduced 
sufficiently. You can build your "web of trust" using signed directories that 
point to other directories, so there shouldn't be that much need for 
keyword-based searches.

> > > * An Anonymous Distributed Computing framework.
<< lots zapped >> 
> We may want this anyway because
> making a genuinely tamperproof sandbox to run random code in is
> probably not the easiest thing to do.

Well, it's called a virtual machine and I can point you to (which, as you know, hosts the GNUnet project's dynamic 
page). OVM is actually what I'm mostly working on (don't bother trying to run 
real Java apps with it at this point, OVM is still barely getting towards 
being alpha-ware (from vapour-ware) and is really a pure research vehicle at 
this point).  Nevertheless, it might be cool to see the two projects converge 
/ cooperate at some point. 

So while we have 200 KLOC of code for the sandbox, I'm not so sure what the 
point of distributed anonymous computation is.  You have to distribute your 
code and input data (which may identify you) and you have to bare the 
additional cost to anonymize that process.  And while for AFS there's no way 
to avoid engaging other parties, for a computation you can always just buy a 
bigger machine yourself (which means no security risks, no attacks on 
anonymity, no sandboxing required, etc.).  In any situation that I can think 
of where I would require strong anonymity and I have the choice between an 
anonymizing network (with network attacks on anonymity) and publishing my 
data and code (which might also be used to deanonymize myself, think of the 
personal information contained in WinWord DOC files and how many people are 
aware of that; now, for distributed computation, the list of subjects is 
going to be taken from people that had access to the input data.  Now, for 
any "secret" application that I can think of, the pool of people that 
actually have access to the input data is probably going to be too small to 
avoid identification by intersection between GNUnet users and people having 
access to the input data...) or alternatively buying computing facilities, I 
would go for the computing facilities :-). 

Oh, and if you wonder why I'm writing these monster sentences, I'm in Germany 
for the next two weeks (and will thus answer E-mail only sporadically or not 
at all) and Germans tend to have the long long sentences with 
multimegalongwordsthatnoenglishspeakercanparse. :-)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]