[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [freehaven-dev] Re: [Freenet-chat] MojoNation
On Wed, Aug 09, 2000 at 06:38:38PM -0500, Brett Wooldridge wrote:
> I was thinking that Freenet could simply apply a "hash cash" like
> algorithm between clients and servers. A client must interact
> with a particular server to initiate a request, right? Before being
> allowed to do so it is given a hash to "factor" (reverse factor I
> guess), when it returns the correct result to the server, its request
> is processed. The complexity of the calculation limits the
> number of requests that can be submitted during a block of time,
> limiting over-publication/over-retrieval. This complexity is
> adjustable -- and could be on a per-server basis -- so the
> operator could run a "cashless" node if they choose. It could
> be as simple as allowing 1 publication per "hash", and say 5
> retrievals -- again adjustable.
>
> Storing/tracking "credits" in the system is probably overkill, IMHO.
> The only difficulty I see is how to allow server-to-server traffic
> to be cashless without a vulnerability to someone taking advantage
> of that to write a "spam server".
>
> brett
I'll give two different answers here, one for if you meant Freenet
above, and one if you actually meant to say Free Haven. :)
Yes, Freenet could use hash-cash or other timewasting puzzles to slow
down attackers. See also:
@InProceedings{JB99,
author = {Ari Juels and John Brainard},
title = {Client Puzzles: A Cryptographic Defense Against Connection Depletion Attacks},
booktitle = {Proceedings of the 1999 Network and Distributed System Security Symposium},
month = {February},
year = {1999},
(Hey David, do we have the postscript for this anywhere?)
But I'm not convinced that Freenet needs it. It has a rudimentary defense
system against spamming already, both against publishing (unpopular data
dies out) and against retrieving (it caches where you retrieve it, so
it's harder to attack many servers at once). These defenses may well
be sufficient -- I'm pretty convinced that they'll work if you tweak
the values correctly, based on the threat models for Freenet that I
currently envision.
And if they're sufficient, why add more complexity? My vote (if I were
involved in Freenet) would be to wait and see if they need it. And
you're right, this notion of requiring server-to-server communication
to do timewasting is potentially tricky -- it seems easily possible that
there are DoS attacks lurking in there.
And if you meant to say Free Haven:
The high latency of our communications medium (mixnet, currently)
would dwarf any puzzle requirements you might introduce to the free
haven protocol.
So this is entirely an issue for the communication medium, not the Free
Haven agents themselves. One commonly noted problem with mixnets is that
they don't have good flooding protection (if you send more mail than
the mixnet can handle, then everything starts to bog down). This would
be a good attack against Free Haven if we were to implement it right now.
It may be that introducing puzzles to the mixnet layer -- requiring the
client to do some more calculations before sending a mail -- would be
a nice way to protect against mixnet flooding.
It's not clear to me that the protection this offers outweighs the
complexity of adding it into the mixnet systems.
A couple of the free haven people (brian and mike) have been actively
thinking about new mixnet ideas lately. Is it time to start that
thread? :)
--Roger