On Sun, 30 Jul 2000, you wrote: <> > Security isn't about making things impossible - it's about raising > the bar to the point where it costs more to compromise the trust of > the machine/network than the data is worth. By increasing the number of > network fingerprints which freenet could use, you're increasing the > number of rules and/or computations a sniffer or trace program would > need to do. Assuming, of course, anyone really cares whether a 3rd > party knows who went where and when. I don't know whether plausible > deniability is a design consideration for freenet.
I'm just weary of the use of the term "impossible" like you did. I get hives every time I read a press story claiming that it is "impossible" to identify a Freenet user. And there _is_ security that makes thing impossible - hash functions, cyphers, and even your mixnet that sent everything in equally large packages sent at regular intervals are all examples. (Deniability is a large consideration, but we can only take it as far as the other things we consider important (accessability, availability) will allow.) > > We want 100 000+ Freenet nodes running. This is not a mode of > > attack (against Freenet - it is by far the best way to attack > > many things) that has me up at night. > > Actually, the best way to crash freenet, IMO, would be to pollute the > keyspace - create lots of replication conflicts/collisions and issue > lots of bogus requests. I'd follow it up by loading BO2K with a custom > java applet that requests bogus information to drown out legitimate > information. 60,000 requests of natalie_portman.jpeg would make that > file a priority for the server.. and it would clear its cache to > accomodate. Freenet's biggest strength - dynamically mirroring high- > demand content, could also be it's biggest weakness. You can pollute the _namespace_ is this way, but that is not the same as the keyspace. As of 0.3 we are introducing a number of keys that are cryptographically tied to the data (CHK, SVK, see the glossary on the page) and thus will be more or less immune to this. The best way to crash Freenet as it is today (0.2) is to run a node that returns bogus data on all requests. Because every false reply means more references back to the bad node, it would slowly pollute the whole system. The 0.3 version takes measures that should make this drastically more difficult (see KSK). Then there are a variety of DoS attacks, though I'm not sure if I agree with the one you describe. If 60,000 trojaned machines are requesting miss Naked and Petrified, I will be pretty damn glad that the network reacts by spreading it rather then chugging away at any request. If anything the "weakness" here is simply that the network is public. A better DoS attack is: find a key that is closer to the targeted data's key then any other on Freenet (even for cryptographically derived keys like all will be from 0.3 onwards, this only takes about double as many tries the number of documents on Freenet, which is doable), and do a distributed attack with thousands of clients sending thousands of requests for that key. Because the data can't be found all/most of the requests will find there way to nodes that the targeted data also clusters to, shutting them down. > > I don't know about your defenition of Slouch, but of like 30 > > developers with cvs access we have only 4-5 doing any work. > I'll see what I can do to raise that number. :) > > ~ Signal 11 > > > _______________________________________________ > Freenet-dev mailing list > Freenet-dev at lists.sourceforge.net > http://lists.sourceforge.net/mailman/listinfo/freenet-dev -- \oskar _______________________________________________ Freenet-dev mailing list Freenet-dev at lists.sourceforge.net http://lists.sourceforge.net/mailman/listinfo/freenet-dev
