On Friday 03 April 2009 13:24:16 vive wrote: > Matthew, > > I completely agree with you. People should not be using freenet to get the > latest and fastest file-sharing technology. Probably not either to get > stronger privacy if they still require very efficient file-sharing. I > cannot see that the current design (as far as I understand it) is aimed > for that.
So what is it aimed at? (And what parts of the current design do you not understand?) > > Requests to make freenet optimized for large-scale file-sharing sounds > like a promising idea to many, but would IMHO require a re-design with > lower security and privacy. These are tradeoffs that you need to make. > > It may be good to make more explicit that part of Freenet is about trading > off efficiency and high-bw/low latency for stronger privacy and the > possibility to avoid various kinds of censorship. These are the benefits. What are we *good at* then? - Darknet: No other deployed network that I know of will provide anonymity and censorship resistance on a pure friend to friend darknet. Tor for example relies on there being a Free World to tunnel to. - Censorship resistance: Freenet gains because it is a content storage network. Theoretically you can do hit and run insertions, although how practical and secure this is, especially as new nodes are very slow and run on opennet, is an open question. It is easier to set up a freesite safely than to set up a tor hidden service safely. On the other hand, a Tor hidden service won't go away after a month if nobody accesses it. - Anonymity: This ought to be what we are good at, but are we? There are some very powerful known attacks! Randomised splitfile encryption will help a lot with inserts and is near zero cost, encrypted tunnels will help a lot but will be very costly, although we can implement Bloom filter sharing at the same time (which may only work on darknet if churn is too high). To focus on anonymity, we can compare with our most obvious "competitor", Tor. Clearly we have different architectures, different threat models and mostly different attacks. In theory Tor provides very strong anonymity, with p(attack success) ~= c^2/n^2 (where c is the number of nodes the attacker owns and n is the total number of nodes on the network). In practice there are many attacks which generally reduce this to c/n, e.g. route selection attacks. But Freenet doesn't offer any quantified anonymity level as far as I know, and there are some very dangerous attacks that will be costly to deal with: datastore seizure (arguably less of a risk on Tor), correlation attacks (require you to be close to the target), mobile attacker source tracing (on opennet, this may be feasible without any particularly serious resources, provided you can identify the insert stream e.g. by predicting the content; randomizing the insert encryption keys will greatly increase the cost of this attack). In terms of attacks that work on both, Sybil is fairly easy on either Tor or opennet Freenet, and very powerful, although in both cases to some degree it is somewhat limited by available bandwidth (but IANATorDev!). Because Tor supports "clients", a global traffic analyst can likely compromise the vast majority of routes by correlating input and output, although this is harder with hidden services (unless the attacker owns the hidden service). Freenet on the other hand doesn't support pure clients, and IMHO is probably a little harder for traffic analysis assuming there is plenty of traffic on most nodes and no bursts, but ultimately both are vulnerable unless they pad their links out to CBR. Intersection attacks on Freenet generally relate to the client level (e.g. messaging clients), whereas on Tor if the hidden host isn't up the website (or whatever) isn't available. Flooding, blending attacks etc are probably much more effective on Tor than on Freenet. So Freenet addresses a lot of problems that Tor doesn't, such as darknet and data storage. On the other hand, Tor addresses some that Freenet doesn't (real time sockets). It is by no means clear that current Freenet is more secure than current Tor, but neither is the converse IMHO especially for some common usage models: lots of Three(four?) Letter Agencies run Tor exit nodes, which they presumably correlate with intercepted traffic data to trace the originators (as well as easier approaches exploiting idiocy); they presumably also run hidden services with the same intention. Whereas attacking large Freenet inserts is arguably even easier, with mobile-attacker source tracing. So both suck IMHO! Which makes Freenet a perpetual research project: Will Freenet ever achieve what neither Freenet nor Tor can achieve right now? Maybe. Randomised splitfile keys will make the main threat (mobile attacker source tracing) much more difficult / slower, but this only helps inserters, and how close the attacker needs to be to the inserter after that point is anyone's guess right now. Tunnels would help a lot but would likely be extremely expensive; whether tunnels plus bloom filters is a net cost or a net benefit to performance is again anyone's guess. Both points need simulations, but simulations always make the wrong assumptions. :) I do think some good attack simulations would buy us some credibility, provided they are published around the same time as a system implementing the above... Ex-cypherpunks will generally go with Tor because they (think they) understand mixnets... Given that we need funds to continue this R&D project we have embarked on, and that we need users to help demonstrate whether it can work in practice (e.g. by building a darknet), who can/should we aim it at? > > /V. > > On Thu, Apr 02, 2009 at 08:18:32PM +0100, Matthew Toseland wrote: > > Freenet can never compete on speed with traditional peer to peer, for several > > reasons, of which at least 1 is intractable: > > 1. Freenet assumes high uptime. This does not happen in practice, at least not > > for the mass market. To some degree we can resolve this with e.g. persistent > > requests in 0.10. > > 2. Freenet returns data via intermediaries, both on darknet and opennet. This > > is what makes our caching model work, and it's a good thing for security, > > however broadcasting a search (or using some more efficient form of lookup) > > and then having those nodes with the data contact you directly will always be > > faster, often much much faster. Caching may well obviate this advantage in > > practice, at least in the medium term. > > 3. Freenet has a relatively low peer count. Hence the maximum transfer is > > determined by the output bandwidths of the peers, which is low. Increasing > > the number of peers will increase various costs, especially if they are slow, > > and make it harder to see whether the network can sclae, otoh it would > > increase maximum download rates... > > 4. Freenet avoids ubernodes. Very fast nodes are seen as a threat, rightly, > > because over-reliance on them makes the network very vulnerable. Practically > > speaking they may be attacked, if this is common it again neutralises this > > advantage of "traditional" p2p. > > 5. FREENET DOESN'T BURST. > > > > The last is the fundamental, intractable issue IMHO. Freenet sends requests at > > a constant rate, and exchanges data between peers at a roughly constant rate. > > On something like Perfect Dark (which admittedly has much higher average > > upstream bandwidth and bigger stores), you start a request, and you get a > > huge great spike until the transfer is complete. It's similar on bittorrent, > > provided the file is popular. On Freenet, our load management is all designed > > to send requests constantly, and in practice, up to a certain level, it will > > use as much bandwidth as you allow it. We could introduce a monthly transfer > > limit as well as the upstream limit, but this would not help much, because > > bursting is inherently dangerous for Freenet's architecture. If you are Eve, > > and you see a big burst of traffic spreading out from Alice, with tons of > > traffic on the first hop, lots on the second, elevated levels on the third, > > you can guess that Alice is making a big request. But it's a lot worse than > > that: If you also own a node where the spike is perceptible, or can get one > > there before the spike ends, you can immediately identify what Alice is > > fetching! The more spiky the traffic, the more security is obliterated. And > > encrypted tunnels do not solve the problem, because they still have to carry > > the same data spike. Ultimately only CBR links solve the problem completely; > > what we have right now is hope that most of the network is busy enough to > > hide traffic flows, but this is the same assumption that many other systems > > rely on. But big spikes - which are necessary if the user wants to queue a > > large download and have it delivered at link speed - make it much worse. > > > > There are lots of ways we can improve Freenet's performance, and we will > > implement some of the more interesting ones in 0.9: For example, sharing > > Bloom filters of our datastore with our peers will gain us a lot, although to > > what degree it can work on opennet is an open question, and encrypted tunnels > > may eat up most of the hops we gain from bloom filters. And new load > > management will help too when we eventually get there. However, at least for > > popular data, we can never achieve the high, transient download rates that > > bursty filesharing networks can. How does that affect our target audience and > > our strategy for getting people to use Freenet in general? Does it affect it? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20090406/373cbb46/attachment.pgp>
