Re: [freenet-support] Freenet speed & local threats
On Monday 12 Dec 2011 01:05:36 Chris wrote: > > If users and organizers are using Tor/freenet/whatever it can be difficult > to determine who is organizing, who is actively participating, and who is > just a supporter, or even follower (may be against the revolt). Compared > to if an organizations members know each other and can be forced to talk. > A government in power may not have the resources to arrest all using > Tor/freenet/whatever. That gives the organizers protection (potentially or > hopefully) long enough to let them carry through from the organization to > the actual uprising without it's organizers being killed off. Or give them > opportunity to make mistakes and re-group. I disagree with most of what you have said. However, the above is more or less on target. You need a lot of people using Freenet who aren't interested in political activism, who are just using it to talk to their friends, share files etc. Then all your Friends can be people you know (so darknet is feasible), and yet they're not all part of your guerilla cell. Also, any good movement needs martyrs. Finally ... look at what people actually used ... Facebook! signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
On Monday 12 Dec 2011 02:24:17 Dennis Nezic wrote: > On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: > > > On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: > > > > > > It's not that they "think" it's hopelessly insecure. It really > > > is :p. I mean, it might still be "good enough" -- but there are > > > actual, well-known, unsolvable problems with the opennet idea. > > > Which that FAQ should have explained :p. > > > > I'm not arguing it is or isn't. Everything is relative though. > > No, everything is not relative :P. Opennet *is* pretty easily > exploitable by design. This isn't a problem with freenet in particular > -- but of any untrustworthy network. (Opennet does actually have a > minimal amount of trust in it -- via the seednodes. But it's easily > exploitable. A darknet is the way to go. (The only reason why the > opennet is still around is because people are lazy and complacent.)) It's a specific problem with not being a mixnet. Unfortunately mixnets are either not scalable or easily blocked or both. However IMHO Freenet can be useful even without being a mixnet. > > > > Nobody is saying you don't need public support (at least until you > > gain power). > > It's the first and main thing you need, before you decide to take any > action. (Unless that action is supposed to persuade them -- which > anything violent or controversial probably almost certainly won't.) Hmmm... when was this email written? ;) > > > If the government is killing off or arresting the organizers then > > gaining popular support is difficult or impossible. > > Well, if they're organizing to "get the revolution rolling", then of > course that's an assured fail. If they're organizing to peacefully > teach people, then yea, arresting those people will hamper things. This > is where freenet might come in. What happened in practice is they posted to facebook pages (sometimes in their real name, sometimes Facebook turned a blind eye, but it is likely to crack down on it now outside of countries where it has no legal exposure and it is fashionable not to cooperate with the authorities), they got traced by the regime and executed, but then their families came out, along with the families of all the people kidnapped and shot by the government at demonstrations... What you really need in such a communication tool is *popularity*. The problem with Facebook is that you are at the whims of a corporation trying to make a profit, whose main asset is *your private information*. The problem with Freenet is even if we get it working well (and we're a long way off that), if it's popular the government will just block it by various rather expensive brute-force methods and bill the customers for the oppression. But generally, the more popular Freenet is, the more useful it is for political purposes. And yes, things like subversive blogs are important. Even in the west, where people get fired, prosecuted etc for blogging about work. > > > The problem is that many people are going to be in great danger as > > they will be physically doing things that might get detected. > > People should not be doing things "physically", before the philosophy > is firmly entrenched in the minds of the people. If the people are > still brainwashed, than any action you take will only make your > position look worse. First you have to undo their brainwashing. Hence blogs etc. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
On Monday 12 Dec 2011 03:26:50 Chris wrote: > > On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: > > > > How would you tell the difference between freenet becoming more > > popular, and the bad guys slowly infiltrating the opennet? Also, you > > assume they only have a few days to perform the attack -- how do you > > know most of the current nodes aren't "them" right now? > > You wouldn't know. But you can't exactly be targeted until you exist. > Second. There are lots of adversaries. Not all of them are going to be > targeting you. If the number of nodes is increasing it makes any one > adversaries job all that much harder to target any one particular user. > The Tor project has said such before. The more nodes that exist the harder > certain attacks are to perform. Many of these attacks become apparent too > if done too quickly. I'm not saying this would work for Freenet. I'm just > saying it depends on the model and various factors. Freenet is very small. > So it Tor. If every computer was distributed with Freenet or Tor many of > these attacks would be much more difficult. Your node should have a choice > as to who to connect with. If you have enough choice you will be unlikely > to come across your adversary given a random selection of nodes. Tor has scalability issues. In principle Freenet should scale better than Tor does. Unfortunately bandwidth is very cheap in quantity. Computing hardware and geeks are cheap too. So even with a big network, it's likely that connecting to and surveilling every node is going to be feasible for a relatively small cost. And in fact a big network would be more likely to contain interesting targets - so is more likely to be surveilled than a small network. This is just the extreme end of opennet attacks though. There are many cheaper attacks, which are partially explained in the FAQ. > > >> The way to do this really is to monitor the data and figure out what > >> the statistics are or have been over time and then base it off this > >> information. If there is a change in those statistics it could > >> indicate an attack. > > > > This is being done. But it won't help in this case at all. (Even if I > > wanted to dump thousands of bugged nodes into the network, I could > > simply post a Slashdot article, and join that upsurge.) > > You could. But then that upsurge would probably make it all the more > difficult to perform the attack. For the record your idea of taking stats doesn't work. It doesn't work because nodes constantly go online and offline, so you need to constantly add more nodes - and many nodes do actually leave for good. It doesn't work because an attacker could perfectly well make his nodes behave in the "predictable" way you expect. And above all it doesn't work because routing on opennet is dependant on the path folding algorithm, which constantly changes the connections to optimise data retrieval. Simply choosing a fixed set of peers at install time does not work, especially not if the network is getting bigger. We do limit the rate of gaining new connections, but we can't limit it to be so slow as to affect an attacker in a big way. An attacker cannot directly connect to your node, he has to use path folding. But there are various attacks that make use of this. The simplest, and most expensive - connect to everyone - simply means he has to be a good node. More sophisticated, cheaper attacks rely on figuring out, with slowly increasingly precision, where a stream of requests are coming from. And yes we have many ideas on how to make these attacks much more difficult, especially for inserts (which generally are more valuable than requests). > > Are you reading what I'm writing? You have to organize first. If you > haven't organized you can't get the people unbrainwashed. Any revolution > takes MANY people. Debatable point in the light of recent events IMHO. > > You clearly would prefer to go out in the street and organize. Good luck > not getting shot. My brothers and sisters and girlfriends and parents will come after me. When they get shot their relatives will come after. When they keep on shooting us we just get bigger. And if they still won't give in, and shoot us some more, the soldiers start defecting to our side, and we still win. I'm not saying you don't need organisers. Certainly inspiring voices are helpful, and keeping them safe is helpful. But look at what has been achieved with essentially traceable, public systems. IMHO Freenet has limited use in revolutions because the authorities will either turn off the internet completely or find some expensive technical way to block it which they can get the people to pay for. However, if it is popular, and allows people to communicate, it can be very useful, not least for helping people to hear voices they wouldn't be able to hear otherwise. China has shown it's willing to tolerate criminality as long as it doesn't include dissent - there is apparently sta
Re: [freenet-support] Freenet speed & local threats
On Friday 09 Dec 2011 14:48:20 Volodya wrote: > On 12/09/2011 02:26 PM, Chris wrote: > > I am looking into setting up a distribution where Tor or freenet is used > > to create a secure and anonymous environment for communicating. > > > > One of the issues with freenet is that it is slow. I haven't used it in > > many years and do understand it has gotten much better. I also am aware > > that after a few days it gets faster as popular data is retained and gets > > 'cached' on your node and nearby nodes based on what those around you are > > doing. > > > > What I'm trying to figure out is what happens when your node is not on > > 24/7 and you can only connect infrequently for several hours at a time. > > > > Many users have a persistent local threat that they need to be aware of. > > Leaving a server running is not an option as it could be compromised by an > > adversary. > > > > Removable media can reduce that threat. What I'm looking to find out is if > > you run a freenode from a removable media and then run a local server > > running freenode to use as one of your peers (which could be on all the > > time) does this post a threat? > > > > If no local server is run that you peer with how is the speed if you only > > connect every few days? Is running freenet for a few hours to several > > hours going to be sufficient or will it be unbearably slow? > > > > With Tor speeds are frequently severely limited. Especially with .onion > > nodes. Some non-onion servers can be accessed with significant speed > > though for sustained periods (15-300... maybe faster). > > The bigger problem with Freenet isn't really speed, it's the latency (i.e. how > long it takes for the data to begin being actually downloaded after request or > be uploaded after the insert starts). That part gets better if you are > connected > after some time. > > Also you didn't state if you are looking for anonymous publishing or anonymous > downloading. If it's for publishing then Freenet will actually be better than > Tor for you, since after the user goes offline the content doesn't disappear, > and the adversary cannot determine the user simply by looking at patterns in > the > accessibility. > > However, if you are looking for something which will protect the user, who > cannot run any software for a long period of time and wants to download the > material right after going online, then perhaps something like Tor is better > (at > this time). > > Of course, what do i know? > > - Volodya The basic problem is if you have a "persistent local threat", they will install a keylogger and know precisely what you are doing. If you're just worried about mum finding some naughty pictures and getting the wrong impression, there are various ways to deal with that. signature.asc Description: This is a digitally signed message part. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 22:26:50 -0500, Chris wrote: > [...] > If you go out and publicly denounce a rouge government you are liable > to get yourself shot long before you have any chance to gather > support. The Internet is a great platform to anonymously gather > support. When everybody comes out at once to support a cause you > won't be shot. There will be too many others for them to notice. This is why I specifically said that your friends and family are where the battle is really at -- not some impersonal public demonstration in front of the bad guys' palace. (If your friends are online, then Freenet is useful. If you expect to teach online strangers, then I believe you will probably fail. Speaking from (extensive!) personal experience :p.) I don't believe "rogue governments" exist. They are all supported by the majority -- probably via ignorance -- but supported nonetheless. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: >> > On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: >> >> How many users actually compile it themselves? >> > >> > Me, and all other Gentoo users :-). >> > >> >> How many examine the diffs? >> > >> > I do, rarely :s. >> > >> > >> >> > [...] >> >> > How would you propose to differentiate between a bugged node and >> >> > a normal node? >> >> >> >> This is why you have authentication and checks against any >> >> inability to connect to nodes. >> > >> > There is no such authentication that would help here. And you would >> > be able to connect to any node normally -- except the compromised >> > nodes would still find a way to become your peers and surround you. >> > (I'm not sure exactly what criteria need to be met for your node to >> > accept a stranger's offer, but I'm sure a dedicated adversary can >> > easily meet them.) >> >> I think you are wrong here. I think authentication could work to a >> degree provided certain conditions are true/consistent enough. I am >> assuming certain things such as there being enough nodes that come >> online daily and stay online permanently. It may not work if the >> number of nodes which come online and then go offline is high. I'm no >> expert here although in theory you should be able to use >> authentication to verify that old nodes are still under the control >> of the person they were under prior. Chances are the initial nodes >> you trust aren't going to be compromised by your adversary. > > First of all, on opennet, the peers you are connected to change every > few minutes/hours. They are not static. They constantly change to make > routing more efficient, via "swapping". I was not suggesting the bad > guys actually compromise other people's nodes -- the far easier and > more likely scenario is they simply have *their own bugged nodes*, and > try to become your peer. (And I think, (not absolutely sure), for a > dedicated attacker, this is pretty easy.) > > >> The adversary would have to slowly bring on new nodes then and would >> be limited to a particular number of nodes per day (however many is >> typical). If they try bringing on too many new nodes at once an alert >> should go up. > > So, again, *their nodes* (just a few... 10-20?) will initiate peering > with your node. And there is nothing you or anyone can do about it. > This is the problem with connecting to strangers -- ie. opennet. > > Although, I guess this can be (already is?) mitigated somewhat if we > only allow a certain percentage of our peers to come from external > (swap, etc) requests -- but then it would simply become a question of > time before you initiate peering with their nodes -- and they will have > many, including big and popular seednodes. > > >> For instance say there are 5000 nodes already, and there are never >> more than 20 new nodes that come on per day then the adversary would >> need 8 months to add 5000 nodes. If they brought on 40 nodes a day it >> would be apparent that an attack was underway. > > How would you tell the difference between freenet becoming more > popular, and the bad guys slowly infiltrating the opennet? Also, you > assume they only have a few days to perform the attack -- how do you > know most of the current nodes aren't "them" right now? You wouldn't know. But you can't exactly be targeted until you exist. Second. There are lots of adversaries. Not all of them are going to be targeting you. If the number of nodes is increasing it makes any one adversaries job all that much harder to target any one particular user. The Tor project has said such before. The more nodes that exist the harder certain attacks are to perform. Many of these attacks become apparent too if done too quickly. I'm not saying this would work for Freenet. I'm just saying it depends on the model and various factors. Freenet is very small. So it Tor. If every computer was distributed with Freenet or Tor many of these attacks would be much more difficult. Your node should have a choice as to who to connect with. If you have enough choice you will be unlikely to come across your adversary given a random selection of nodes. > > >> The way to do this really is to monitor the data and figure out what >> the statistics are or have been over time and then base it off this >> information. If there is a change in those statistics it could >> indicate an attack. > > This is being done. But it won't help in this case at all. (Even if I > wanted to dump thousands of bugged nodes into the network, I could > simply post a Slashdot article, and join that upsurge.) You could. But then that upsurge would probably make it all the more difficult to perform the attack. > > >> >> You are looking at the issue wrong. It doesn't matter which nodes >> >> are bugged. If a user can't connect to higher than normal >> >> percentage of nodes it should send up a red flag for one. >> > >> > They will be able to. >> >> They will be able to what? > > They will be abl
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 20:05:36 -0500, Chris wrote: > > On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: > >> How many users actually compile it themselves? > > > > Me, and all other Gentoo users :-). > > > >> How many examine the diffs? > > > > I do, rarely :s. > > > > > >> > [...] > >> > How would you propose to differentiate between a bugged node and > >> > a normal node? > >> > >> This is why you have authentication and checks against any > >> inability to connect to nodes. > > > > There is no such authentication that would help here. And you would > > be able to connect to any node normally -- except the compromised > > nodes would still find a way to become your peers and surround you. > > (I'm not sure exactly what criteria need to be met for your node to > > accept a stranger's offer, but I'm sure a dedicated adversary can > > easily meet them.) > > I think you are wrong here. I think authentication could work to a > degree provided certain conditions are true/consistent enough. I am > assuming certain things such as there being enough nodes that come > online daily and stay online permanently. It may not work if the > number of nodes which come online and then go offline is high. I'm no > expert here although in theory you should be able to use > authentication to verify that old nodes are still under the control > of the person they were under prior. Chances are the initial nodes > you trust aren't going to be compromised by your adversary. First of all, on opennet, the peers you are connected to change every few minutes/hours. They are not static. They constantly change to make routing more efficient, via "swapping". I was not suggesting the bad guys actually compromise other people's nodes -- the far easier and more likely scenario is they simply have *their own bugged nodes*, and try to become your peer. (And I think, (not absolutely sure), for a dedicated attacker, this is pretty easy.) > The adversary would have to slowly bring on new nodes then and would > be limited to a particular number of nodes per day (however many is > typical). If they try bringing on too many new nodes at once an alert > should go up. So, again, *their nodes* (just a few... 10-20?) will initiate peering with your node. And there is nothing you or anyone can do about it. This is the problem with connecting to strangers -- ie. opennet. Although, I guess this can be (already is?) mitigated somewhat if we only allow a certain percentage of our peers to come from external (swap, etc) requests -- but then it would simply become a question of time before you initiate peering with their nodes -- and they will have many, including big and popular seednodes. > For instance say there are 5000 nodes already, and there are never > more than 20 new nodes that come on per day then the adversary would > need 8 months to add 5000 nodes. If they brought on 40 nodes a day it > would be apparent that an attack was underway. How would you tell the difference between freenet becoming more popular, and the bad guys slowly infiltrating the opennet? Also, you assume they only have a few days to perform the attack -- how do you know most of the current nodes aren't "them" right now? > The way to do this really is to monitor the data and figure out what > the statistics are or have been over time and then base it off this > information. If there is a change in those statistics it could > indicate an attack. This is being done. But it won't help in this case at all. (Even if I wanted to dump thousands of bugged nodes into the network, I could simply post a Slashdot article, and join that upsurge.) > >> You are looking at the issue wrong. It doesn't matter which nodes > >> are bugged. If a user can't connect to higher than normal > >> percentage of nodes it should send up a red flag for one. > > > > They will be able to. > > They will be able to what? They will be able to connect to normal nodes too. Of course, from your perspective, they're *all* equal strangers. (On opennet.) > >> I don't doubt that some developers think opennet mode is hopelessly > >> insecure. > > > > It's not that they "think" it's hopelessly insecure. It really > > is :p. I mean, it might still be "good enough" -- but there are > > actual, well-known, unsolvable problems with the opennet idea. > > Which that FAQ should have explained :p. > > I'm not arguing it is or isn't. Everything is relative though. No, everything is not relative :P. Opennet *is* pretty easily exploitable by design. This isn't a problem with freenet in particular -- but of any untrustworthy network. (Opennet does actually have a minimal amount of trust in it -- via the seednodes. But it's easily exploitable. A darknet is the way to go. (The only reason why the opennet is still around is because people are lazy and complacent.)) > >> I think the best way to organize a revolt or guerrilla war fare in > >> todays world would probably be to anonymously organize multiple > >> small group
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: >> How many users actually compile it themselves? > > Me, and all other Gentoo users :-). > >> How many examine the diffs? > > I do, rarely :s. > > >> > [...] >> > How would you propose to differentiate between a bugged node and a >> > normal node? >> >> This is why you have authentication and checks against any inability >> to connect to nodes. > > There is no such authentication that would help here. And you would be > able to connect to any node normally -- except the compromised nodes > would still find a way to become your peers and surround you. (I'm not > sure exactly what criteria need to be met for your node to accept > a stranger's offer, but I'm sure a dedicated adversary can easily meet > them.) I think you are wrong here. I think authentication could work to a degree provided certain conditions are true/consistent enough. I am assuming certain things such as there being enough nodes that come online daily and stay online permanently. It may not work if the number of nodes which come online and then go offline is high. I'm no expert here although in theory you should be able to use authentication to verify that old nodes are still under the control of the person they were under prior. Chances are the initial nodes you trust aren't going to be compromised by your adversary. The adversary would have to slowly bring on new nodes then and would be limited to a particular number of nodes per day (however many is typical). If they try bringing on too many new nodes at once an alert should go up. For instance say there are 5000 nodes already, and there are never more than 20 new nodes that come on per day then the adversary would need 8 months to add 5000 nodes. If they brought on 40 nodes a day it would be apparent that an attack was underway. The way to do this really is to monitor the data and figure out what the statistics are or have been over time and then base it off this information. If there is a change in those statistics it could indicate an attack. > >> You are looking at the issue wrong. It doesn't matter which nodes are >> bugged. If a user can't connect to higher than normal percentage of >> nodes it should send up a red flag for one. > > They will be able to. They will be able to what? > >> You can keep track of nodes as well and check out which nodes are new >> and which have been added over time. The number of new nodes coming >> online shouldn't exceed a certain threshold. If there are 5,000 and >> on average the number of nodes increase by 2 a week then 100 new >> nodes coming online should send up a red flag. I don't know what the >> actual numbers are or the range. Maybe some weeks do see 100 nodes >> and others only 2. There is probably a number though that could >> increase the time it takes to pull off such an attack. > > There is no such metric -- a slashdot article, for example, could > easily trigger such a gauge. Moreover, you're not understanding the > attack enough -- the bad guys don't need to control too many bugged > nodes -- just a few which they will find a way to peer with you. > > By the way, here is one freesite that tries to measure how many nodes > are on the network: > > USK@85gZTCiQO9IEPDAGvjktO9d-ZMS1lIABR6JB85m4ens,VGDItiCVzCcWAay51faZzcIfAepzeHpzXYvChlueWYE,AQACAAE/stats/1533/ > > >> >> and if is not made apparent that is a problem with freenet (or >> >> whichever project you would be suggesting). >> > >> > Yes it is. And that's why it's in the FAQ :p. You should take a bit >> > more time, and read it more carefully: >> > >> > "Combined with harvesting and adaptive search attacks, [the >> > bootstrapping attack] explains why opennet is regarded by many >> > core developers as hopelessly insecure. If you want good security >> > you need to connect only to friends." >> >> I don't think you understand how it works that well. I suspect if >> some of your friends are compromised you won't be. > > Did you even read the "Correlation attacks" subsection, from > http://freenetproject.org/faq.html#attack ? Yes. I get the jist of it. > > >> I don't doubt that some developers think opennet mode is hopelessly >> insecure. > > It's not that they "think" it's hopelessly insecure. It really is :p. I > mean, it might still be "good enough" -- but there are actual, > well-known, unsolvable problems with the opennet idea. Which that FAQ > should have explained :p. I'm not arguing it is or isn't. Everything is relative though. > > >> I think the best way to organize a revolt or guerrilla war fare in >> todays world would probably be to anonymously organize multiple small >> groups. > > I strongly disagree. The battle (no matter which one you pick, > probably) is ultimately in the minds of the boring violence-phobic > masses -- the majorities. If you don't have popular support, you're > doomed no matter what you try to do. The best way to organize a revolt > is to talk to your friends and family and convince them
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 16:36:53 -0500, Chris wrote: > How many users actually compile it themselves? Me, and all other Gentoo users :-). > How many examine the diffs? I do, rarely :s. > > [...] > > How would you propose to differentiate between a bugged node and a > > normal node? > > This is why you have authentication and checks against any inability > to connect to nodes. There is no such authentication that would help here. And you would be able to connect to any node normally -- except the compromised nodes would still find a way to become your peers and surround you. (I'm not sure exactly what criteria need to be met for your node to accept a stranger's offer, but I'm sure a dedicated adversary can easily meet them.) > You are looking at the issue wrong. It doesn't matter which nodes are > bugged. If a user can't connect to higher than normal percentage of > nodes it should send up a red flag for one. They will be able to. > You can keep track of nodes as well and check out which nodes are new > and which have been added over time. The number of new nodes coming > online shouldn't exceed a certain threshold. If there are 5,000 and > on average the number of nodes increase by 2 a week then 100 new > nodes coming online should send up a red flag. I don't know what the > actual numbers are or the range. Maybe some weeks do see 100 nodes > and others only 2. There is probably a number though that could > increase the time it takes to pull off such an attack. There is no such metric -- a slashdot article, for example, could easily trigger such a gauge. Moreover, you're not understanding the attack enough -- the bad guys don't need to control too many bugged nodes -- just a few which they will find a way to peer with you. By the way, here is one freesite that tries to measure how many nodes are on the network: USK@85gZTCiQO9IEPDAGvjktO9d-ZMS1lIABR6JB85m4ens,VGDItiCVzCcWAay51faZzcIfAepzeHpzXYvChlueWYE,AQACAAE/stats/1533/ > >> and if is not made apparent that is a problem with freenet (or > >> whichever project you would be suggesting). > > > > Yes it is. And that's why it's in the FAQ :p. You should take a bit > > more time, and read it more carefully: > > > > "Combined with harvesting and adaptive search attacks, [the > > bootstrapping attack] explains why opennet is regarded by many > > core developers as hopelessly insecure. If you want good security > > you need to connect only to friends." > > I don't think you understand how it works that well. I suspect if > some of your friends are compromised you won't be. Did you even read the "Correlation attacks" subsection, from http://freenetproject.org/faq.html#attack ? > I don't doubt that some developers think opennet mode is hopelessly > insecure. It's not that they "think" it's hopelessly insecure. It really is :p. I mean, it might still be "good enough" -- but there are actual, well-known, unsolvable problems with the opennet idea. Which that FAQ should have explained :p. > I think the best way to organize a revolt or guerrilla war fare in > todays world would probably be to anonymously organize multiple small > groups. I strongly disagree. The battle (no matter which one you pick, probably) is ultimately in the minds of the boring violence-phobic masses -- the majorities. If you don't have popular support, you're doomed no matter what you try to do. The best way to organize a revolt is to talk to your friends and family and convince them peacefully and rationally. (And freenet is a great tool for this! :D.) ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
> On Sun, 11 Dec 2011 01:04:09 -0500, Chris wrote: >> [...] >> I would put money on them taking advantage of zero day exploits >> and/or the courts to force the Tor project, the Freenet project, the >> i2p project, or any other similar project to modify the code and >> insert a back door. Germany did this many years ago with one project >> and successfully identified a user. It was none of the above projects >> although the ability to force upon developers code changes that go >> out to all users has occurred. They were targeting one individual too >> that appeared to be a fairly low-value target. The only thing that >> might stop this from happening to other projects is where the >> developers are operating in one country and the government attempting >> to force the change is in another. > > Another thing that might stop this from happening is open source > software, and at least a bunch of coders reviewing and signing any code > before it gets released. (I'm actually not sure how many coders have to > currently sign -- surely it's not just Toad?) It mitigates it to a degree although the concern still exists. For a few reasons. The party who distributes the binary is going to be ordered not to reveal the modifications. The main page/download page isn't going to warn users and that is likely the only information they are going to see before updating. It becomes newsworthy information though so there is a slight chance a user who keeps up on this stuff would notice prior to installation. The court could order the source code not be released for the new binary too. At least not the code that matches the new binary. Then users would need to actually notice the binary differs from the source code and disassemble it to find the bug. How many users actually compile it themselves? How many examine the diffs? > > Do you have a link or more info on that German case? Was it open-source > software? Did the developer willingly co-operate, or did they use some > kind of backwards legal mechanism to force him? I wonder how much I can > buy Toad for. Everyone has a price ;-). > JAP. Here is some more info on it: http://smokeys.wordpress.com/tag/java-anonymous-proxy/ This may be the most serious breach I have ever heard of with any software and could potentially threaten other projects. The danger was detected right away as the softwares source code was available. Many users updated and were compromised before they became aware of this though. In this instance they were targeting a particular individual although compromised every user of the service. The individual they caught may not have been the same person they were targeting. This is a risk with mass surveillance/search/DNA... > >> > The whole point of opennet is to be able to connect to anybody you >> > want :P. And if your ISP is compromised, this becomes even more >> > trivial -- they can block all but their own seednodes, so you're >> > forced to only connect to their bugged nodes as peers. >> >> This should become apparent to the user > > How would you propose to differentiate between a bugged node and a > normal node? This is why you have authentication and checks against any inability to connect to nodes. You are looking at the issue wrong. It doesn't matter which nodes are bugged. If a user can't connect to higher than normal percentage of nodes it should send up a red flag for one. You can keep track of nodes as well and check out which nodes are new and which have been added over time. The number of new nodes coming online shouldn't exceed a certain threshold. If there are 5,000 and on average the number of nodes increase by 2 a week then 100 new nodes coming online should send up a red flag. I don't know what the actual numbers are or the range. Maybe some weeks do see 100 nodes and others only 2. There is probably a number though that could increase the time it takes to pull off such an attack. I realize you do not have thousands of peers with freenet. This is just an example of how the difficulty of an attack may be reduced with some designs. > >> and if is not made apparent that is a problem with freenet (or >> whichever project you would be suggesting). > > Yes it is. And that's why it's in the FAQ :p. You should take a bit > more time, and read it more carefully: > > "Combined with harvesting and adaptive search attacks, [the > bootstrapping attack] explains why opennet is regarded by many > core developers as hopelessly insecure. If you want good security you > need to connect only to friends." > I don't think you understand how it works that well. I suspect if some of your friends are compromised you won't be. I'm not reading this bootstrap attack as you understand it. I don't doubt that some developers think opennet mode is hopelessly insecure. > >> > [...] >> > In darknet, you *explicitly* specify who to connect to (hopefully a >> > trusted friend), and you don't connect to anybody else. So, to >> > infiltrate this setup, the ba
Re: [freenet-support] Freenet speed & local threats
On Sun, 11 Dec 2011 01:04:09 -0500, Chris wrote: > [...] > I would put money on them taking advantage of zero day exploits > and/or the courts to force the Tor project, the Freenet project, the > i2p project, or any other similar project to modify the code and > insert a back door. Germany did this many years ago with one project > and successfully identified a user. It was none of the above projects > although the ability to force upon developers code changes that go > out to all users has occurred. They were targeting one individual too > that appeared to be a fairly low-value target. The only thing that > might stop this from happening to other projects is where the > developers are operating in one country and the government attempting > to force the change is in another. Another thing that might stop this from happening is open source software, and at least a bunch of coders reviewing and signing any code before it gets released. (I'm actually not sure how many coders have to currently sign -- surely it's not just Toad?) Do you have a link or more info on that German case? Was it open-source software? Did the developer willingly co-operate, or did they use some kind of backwards legal mechanism to force him? I wonder how much I can buy Toad for. Everyone has a price ;-). > > The whole point of opennet is to be able to connect to anybody you > > want :P. And if your ISP is compromised, this becomes even more > > trivial -- they can block all but their own seednodes, so you're > > forced to only connect to their bugged nodes as peers. > > This should become apparent to the user How would you propose to differentiate between a bugged node and a normal node? > and if is not made apparent that is a problem with freenet (or > whichever project you would be suggesting). Yes it is. And that's why it's in the FAQ :p. You should take a bit more time, and read it more carefully: "Combined with harvesting and adaptive search attacks, [the bootstrapping attack] explains why opennet is regarded by many core developers as hopelessly insecure. If you want good security you need to connect only to friends." > > [...] > > In darknet, you *explicitly* specify who to connect to (hopefully a > > trusted friend), and you don't connect to anybody else. So, to > > infiltrate this setup, the bad guys would have to physically > > compromise your friends' nodes, one by one. To infiltrate opennet, > > they just have to type on a keyboard in the comfort of their homes. > > If you could trust your friends there wouldn't be any need for > freenet. The problem is you can't trust anybody. If you can't trust anybody, then what do you hope to achieve? Who do you hope to communicate with -- if everyone is your enemy? ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
> On Sat, 10 Dec 2011 20:06:10 -0500, Chris wrote: >> > On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: >> >> >> [...] >> >> >> Many users have a persistent local threat that they need to be >> >> >> aware of. Leaving a server running is not an option as it could >> >> >> be compromised by an adversary. >> >> >> >> >> >> Removable media can reduce that threat. >> >> >> [...] >> >> >> >> I was not referring to zero day exploits actually. The key word >> >> here was local real-world threats. Such as an adversary gaining >> >> physical access to the server/machine running freenode. >> > >> > If the bad guys have physical access, and care, it's game over. >> > >> > I suppose you can try setting secret tripwires that might notify you >> > if the machine was tampered with (both in software, and in >> > hardware.) Those might give you a fighting chance. Although you'll >> > also need to make sure your room wasn't bugged with pin-hole >> > cameras and other spy-ware. It's a lost battle, regardless. >> >> This is completely dependent on who the adversary is, the level of >> sophistication, mistakes they may make, the resources they may have, >> how badly they want you, what they know about you, and what other >> precautions have been taken. A pin-hole camera for instance should >> not be enough to compromise a good setup. > > How do you figure? (The camera can see everything you're typing and > your screen, right? If you have any additional biometric login > requirements, they can easily be gotten from you later.) Where exactly is this camera placed? This is dependent on the user being position such that a camera can see the keyboard. > >> Nor should a MBR level key logger installation. These two things are >> easier to do than a BIOS level modification. A BIOS level >> modification gets a lot more complicated as each system uses a >> different BIOS. When there is no generic solution to a problem or >> that solution is more cumbersome it may not exist. If it does exist >> it may be used much more selectively and there will almost certainly >> be fewer adversaries who have access to it. You may not be a target >> of a significantly high level adversary (where such levels may exist). >> >> > >> >> Removable media may not eliminate the threat although there is less >> >> opertunity for a more sophisticated targeted attack. A software >> >> keylogger inserted into the MBR or similar would not be possible if >> >> the boot medium is never available to the attacker. >> > >> > But it will be available if you ever decide to boot, happily >> > recording everything. >> >> If the adversary does not have access to your boot medium how do you >> think they are going to install it? When you do boot it should not >> exist. There are few places that a keylogger or device can be >> installed. BIOS, optical drive, USB port, PC card slot, firewire, >> network etc. These are all things that can be checked. The only >> exception is the BIOS. The BIOS differs from machine to machine which >> should increase the cost of the adversary to produce a solution. I >> have never heard of a BIOS level bug. There have been conceptual >> modifications to suggest it may be possible although nothing in >> practice to show it could be done easily. >> >> >Again, if you think your machine was actually tampered >> > with, you should assume it's unusable. >> >> Nobody is arguing that a knowingly compromised machine or one that >> there is reason to suspect could have been compromised should be used. > > But any machine that the adversary has physical access to should be > suspected to have been compromised. A BIOS-level bug, as you explain, > is one great way. Personally, I would prefer lower-tech spy solutions. > Of course, you can assume your adversary is weak, but that's a risky > assumption. If I'm the adversary the question becomes how do I go about producing a bug for every machine that I might come across that I would like to bug? Porting BIOS modifications from one motherboard to another is a non-trivial task and would be prohibitively expensive. Probably even for the wealthiest nations on earth. There are easier ways to bug that .0001% of the population who might have a bug-resistant setup. Of that .0001% there are probably a handful currently whom a BIOS level bug would be needed. There are projects out there to port an open source BIOS and there are at best 100 boards which are supported. Of that there are just 5 laptops. If you think 5 models is a lot think again. Of any specific laptop it takes a specific revision of that laptop. This is a project which has bee around for many many many years with financial support from governments and corporations. Even if we assume the governments have access to the original source code to every BIOS (which you would have to have one for each model and revision of every laptop) it is still going to be expensive. Who are you that the government is going to have the technical persons on hand to arrange
Re: [freenet-support] Freenet speed & local threats
On Sat, 10 Dec 2011 20:06:10 -0500, Chris wrote: > > On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: > >> >> [...] > >> >> Many users have a persistent local threat that they need to be > >> >> aware of. Leaving a server running is not an option as it could > >> >> be compromised by an adversary. > >> >> > >> >> Removable media can reduce that threat. > >> >> [...] > >> > >> I was not referring to zero day exploits actually. The key word > >> here was local real-world threats. Such as an adversary gaining > >> physical access to the server/machine running freenode. > > > > If the bad guys have physical access, and care, it's game over. > > > > I suppose you can try setting secret tripwires that might notify you > > if the machine was tampered with (both in software, and in > > hardware.) Those might give you a fighting chance. Although you'll > > also need to make sure your room wasn't bugged with pin-hole > > cameras and other spy-ware. It's a lost battle, regardless. > > This is completely dependent on who the adversary is, the level of > sophistication, mistakes they may make, the resources they may have, > how badly they want you, what they know about you, and what other > precautions have been taken. A pin-hole camera for instance should > not be enough to compromise a good setup. How do you figure? (The camera can see everything you're typing and your screen, right? If you have any additional biometric login requirements, they can easily be gotten from you later.) > Nor should a MBR level key logger installation. These two things are > easier to do than a BIOS level modification. A BIOS level > modification gets a lot more complicated as each system uses a > different BIOS. When there is no generic solution to a problem or > that solution is more cumbersome it may not exist. If it does exist > it may be used much more selectively and there will almost certainly > be fewer adversaries who have access to it. You may not be a target > of a significantly high level adversary (where such levels may exist). > > > > >> Removable media may not eliminate the threat although there is less > >> opertunity for a more sophisticated targeted attack. A software > >> keylogger inserted into the MBR or similar would not be possible if > >> the boot medium is never available to the attacker. > > > > But it will be available if you ever decide to boot, happily > > recording everything. > > If the adversary does not have access to your boot medium how do you > think they are going to install it? When you do boot it should not > exist. There are few places that a keylogger or device can be > installed. BIOS, optical drive, USB port, PC card slot, firewire, > network etc. These are all things that can be checked. The only > exception is the BIOS. The BIOS differs from machine to machine which > should increase the cost of the adversary to produce a solution. I > have never heard of a BIOS level bug. There have been conceptual > modifications to suggest it may be possible although nothing in > practice to show it could be done easily. > > >Again, if you think your machine was actually tampered > > with, you should assume it's unusable. > > Nobody is arguing that a knowingly compromised machine or one that > there is reason to suspect could have been compromised should be used. But any machine that the adversary has physical access to should be suspected to have been compromised. A BIOS-level bug, as you explain, is one great way. Personally, I would prefer lower-tech spy solutions. Of course, you can assume your adversary is weak, but that's a risky assumption. > >> On the other hand a physical keylogger may still be possible and > >> maybe even a software based keylogger although more difficult to > >> disguise/install without being noticed. > > > > Of course. You should expect a variety of key loggers installed, in > > code, under your keyboard keys, acoustic key loggers stuck somewhere > > inside the machine (that can acoustically determine which key you're > > pressing), and a bunch throughout your room in pin holes in your > > walls and ceiling. > > None of which can't be avoided. As far as I know. Please explain. > >> I can think of at least a few different ways of getting a keylogger > >> onto a system without having access to the boot drive or having to > >> install a physical device. I would still need physical access to > >> the computer. At least one method would not even require BIOS > >> modification and would work on any x86 machine. > > > > So you're already aware that there is not much hope if the bad guys > > get physical access? :p > > I disagree. Most "bad guys" aren't as sophisticated as one might > think. Including the ones coding the bugs and exploits used. They > will create a bug and assume it works. In reality it only works if x, > y, and z are true. Provided you have taken sufficient precautions > this rarely is the case. Most adversaries need not be sophisticated > at all. They me
Re: [freenet-support] Freenet speed & local threats
On Fri, 9 Dec 2011 17:29:33 -0500, Chris wrote: > >> [...] > >> Many users have a persistent local threat that they need to be > >> aware of. Leaving a server running is not an option as it could be > >> compromised by an adversary. > >> > >> Removable media can reduce that threat. > >> [...] > > I was not referring to zero day exploits actually. The key word here > was local real-world threats. Such as an adversary gaining physical > access to the server/machine running freenode. If the bad guys have physical access, and care, it's game over. I suppose you can try setting secret tripwires that might notify you if the machine was tampered with (both in software, and in hardware.) Those might give you a fighting chance. Although you'll also need to make sure your room wasn't bugged with pin-hole cameras and other spy-ware. It's a lost battle, regardless. > Removable media may not eliminate the threat although there is less > opertunity for a more sophisticated targeted attack. A software > keylogger inserted into the MBR or similar would not be possible if > the boot medium is never available to the attacker. But it will be available if you ever decide to boot, happily recording everything. Again, if you think your machine was actually tampered with, you should assume it's unusable. > On the other hand a physical keylogger may still be possible and maybe > even a software based keylogger although more difficult to > disguise/install without being noticed. Of course. You should expect a variety of key loggers installed, in code, under your keyboard keys, acoustic key loggers stuck somewhere inside the machine (that can acoustically determine which key you're pressing), and a bunch throughout your room in pin holes in your walls and ceiling. > I can think of at least a few different ways of getting a keylogger > onto a system without having access to the boot drive or having to > install a physical device. I would still need physical access to the > computer. At least one method would not even require BIOS > modification and would work on any x86 machine. So you're already aware that there is not much hope if the bad guys get physical access? :p > [...] > Lets give a scenario: > > We have to assume that a persons Internet connection is being > monitored. This might be via a sophisticated non-governmental actor > (such as by breaking WEP/WPA) or by a government act such as > monitoring at the telco. The adversary should also be assumed to be > "unethical" in that there are no rules In that case, if you're using only opennet-mode, you should assume you're screwed :p. They can replace all your opennet peered nodes, and see exactly what you're doing, more or less. This is why darknet-mode was created -- they would need to physically infiltrate all your friend's computers, which isn't impossible, but MUCH more difficult. > and can physically modify or otherwise install a software based > monitoring solution on any boot media they have access to. Then you're *definitely* screwed, regardless, as explained above. > The first question is how many peers need to be compromised to > identify the content being transmitted? All of them, to be 100% sure. Compromising opennet peers is trivial -- with a dedicated-enough adversary. Compromising darknet is a lot harder. > If a few of your freenode peers can be compromised and the adversary > can monitor your Internet connection and local area network can they > identify the contents which are being requested/sent by you? This > assumes that they can't bug the physical machine that you are using > to run freenode. As long as you still have one uncompromised peer, I guess they can't be sure what traffic you're generating locally, and what you're simply relaying for that peer (or that peer's peers, etc). But if they're able to compromise all-but-one of your peers, it's pretty darn close to game-over :p. If I was an unethical bad guy, I'd arrest you and that peer, separate you into isolation-cells, and play psychological games until one of you confesses. Or perhaps torture. (Although, if that other peer doesn't have anything to hide, or isn't your friend, I'd easily jump to the conclusion that you're the one I'm looking for :). > If you add a server with freenode (which can be bugged) to your local > LAN that is then added as one of your peers does this compromise the > security? The point of adding a server with freenode to peer with on > the local LAN would be to speed up requests since the machine that is > actually used for browsing freesites (such as a laptop) can't be left > on all the time (as doing so gives an adversary opportunity to bug > it). This means it has to run from a removable boot medium that can > be accounted for at all times. Overlooking the above points about physically-tampered machines (we *really* shouldn't overlook them), I think this setup essentially means that you can expect one of your lan peers to be compromised. But, as long a
Re: [freenet-support] Freenet speed & local threats
> On Fri, 9 Dec 2011 05:26:19 -0500, Chris wrote: >> I am looking into setting up a distribution where Tor or freenet is >> used to create a secure and anonymous environment for communicating. > > Very cool. I've done that too :-). > >> One of the issues with freenet is that it is slow. I haven't used it >> in many years and do understand it has gotten much better. I also am >> aware that after a few days it gets faster as popular data is >> retained and gets 'cached' on your node and nearby nodes based on >> what those around you are doing. >> >> What I'm trying to figure out is what happens when your node is not on >> 24/7 and you can only connect infrequently for several hours at a >> time. > > It runs at esssentially the same speed (minus the benefits of immediate > local caching, of course) -- which is pretty slow but manageable. It > may take a few seconds / a minute longer to fetch things, but that's > still a minute longer than the censored web provides, so either way > users will have to adjust their expectations. Booting into the network > will also take an additional minute or so, which always-on nodes don't > have to worry about. > >> Many users have a persistent local threat that they need to be aware >> of. Leaving a server running is not an option as it could be >> compromised by an adversary. >> >> Removable media can reduce that threat. > > The keyword being *reduce* :p. We all have that concern and fear, of > unforeseen zero-day linux exploits, etc. (We already know they exist in > Window$ :). Ideally you would want to make extra sure you have "enough" > contingency planning (proper permissioning / stable and patched > software / firewalls / perhaps "caged" virtual machines / "sentry" > programs / whatever your paranoia desires), so such fears are > minimized. They will never be eliminated though. > I was not referring to zero day exploits actually. The key word here was local real-world threats. Such as an adversary gaining physical access to the server/machine running freenode. Removable media may not eliminate the threat although there is less opertunity for a more sophisticated targeted attack. A software keylogger inserted into the MBR or similar would not be possible if the boot medium is never available to the attacker. On the other hand a physical keylogger may still be possible and maybe even a software based keylogger although more difficult to disguise/install without being noticed. I can think of at least a few different ways of getting a keylogger onto a system without having access to the boot drive or having to install a physical device. I would still need physical access to the computer. At least one method would not even require BIOS modification and would work on any x86 machine. >> What I'm looking to find out is if you run a freenode from a >> removable media and then run a local server running freenode to use >> as one of your peers (which could be on all the time) does this post >> a threat? > > Besides the obvious risks of either of those machines being compromised > (by any number of ways: physically, buggy software, leaky software, > etc), traffic analysis will always be a threat with Tor, and also with > Freenet if bad guys have somehow managed to occupy all your peer > connections. But besides these well known threats, I think it's pretty > safe. But not perfectly safe. Lets give a scenario: We have to assume that a persons Internet connection is being monitored. This might be via a sophisticated non-governmental actor (such as by breaking WEP/WPA) or by a government act such as monitoring at the telco. The adversary should also be assumed to be "unethical" in that there are no rules and can physically modify or otherwise install a software based monitoring solution on any boot media they have access to. The first question is how many peers need to be compromised to identify the content being transmitted? If a few of your freenode peers can be compromised and the adversary can monitor your Internet connection and local area network can they identify the contents which are being requested/sent by you? This assumes that they can't bug the physical machine that you are using to run freenode. If you add a server with freenode (which can be bugged) to your local LAN that is then added as one of your peers does this compromise the security? The point of adding a server with freenode to peer with on the local LAN would be to speed up requests since the machine that is actually used for browsing freesites (such as a laptop) can't be left on all the time (as doing so gives an adversary opportunity to bug it). This means it has to run from a removable boot medium that can be accounted for at all times. > >> If no local server is run that you peer with how is the speed if you >> only connect every few days? Is running freenet for a few hours to >> several hours going to be sufficient or will it be unbearably slow? > > It's bearable. (After it takes a few minutes t
Re: [freenet-support] Freenet speed & local threats
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2011 02:26 PM, Chris wrote: > I am looking into setting up a distribution where Tor or freenet is used > to create a secure and anonymous environment for communicating. > > One of the issues with freenet is that it is slow. I haven't used it in > many years and do understand it has gotten much better. I also am aware > that after a few days it gets faster as popular data is retained and gets > 'cached' on your node and nearby nodes based on what those around you are > doing. > > What I'm trying to figure out is what happens when your node is not on > 24/7 and you can only connect infrequently for several hours at a time. > > Many users have a persistent local threat that they need to be aware of. > Leaving a server running is not an option as it could be compromised by an > adversary. > > Removable media can reduce that threat. What I'm looking to find out is if > you run a freenode from a removable media and then run a local server > running freenode to use as one of your peers (which could be on all the > time) does this post a threat? > > If no local server is run that you peer with how is the speed if you only > connect every few days? Is running freenet for a few hours to several > hours going to be sufficient or will it be unbearably slow? > > With Tor speeds are frequently severely limited. Especially with .onion > nodes. Some non-onion servers can be accessed with significant speed > though for sustained periods (15-300... maybe faster). The bigger problem with Freenet isn't really speed, it's the latency (i.e. how long it takes for the data to begin being actually downloaded after request or be uploaded after the insert starts). That part gets better if you are connected after some time. Also you didn't state if you are looking for anonymous publishing or anonymous downloading. If it's for publishing then Freenet will actually be better than Tor for you, since after the user goes offline the content doesn't disappear, and the adversary cannot determine the user simply by looking at patterns in the accessibility. However, if you are looking for something which will protect the user, who cannot run any software for a long period of time and wants to download the material right after going online, then perhaps something like Tor is better (at this time). Of course, what do i know? - Volodya - -- http://freedom.libsyn.com/ Echo of Freedom, Radical Podcast "None of us are free until all of us are free."~ Mihail Bakunin -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJO4h+zAAoJENW9VI+wmYasPPgH/14AOhfo+xW9120RMdxegXYf 81daeoCtFwpYWMKk3flevH9HyjeKdbZymt6sqVq1z90/IPYMz9jXnERKaAGKdegE cm2Sly0Kg6JkJ+e/sQu3nIKkWcKHv3AsNg9rtp1Kd5Qpe4tpau4V221aZiXLkGtA RvBL8pKUBNYBq8k5usxVV9m4jArfIYeUN2xcq+BXXwf5Gi/mC4uvov6WAe5VTTOS Q4bXexqtc1KNnali15uT6EdQqmsac9u/8aVYgeA359etPtHGWvKxyctmpgJuypbS xE7eoiSstA5gibcd8wIKzIrfOhz92WcC4br2qicwnIy77jq6hPNbqrnFMP8D3Rk= =T3EK -END PGP SIGNATURE- ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
Re: [freenet-support] Freenet speed & local threats
On Fri, 9 Dec 2011 05:26:19 -0500, Chris wrote: > I am looking into setting up a distribution where Tor or freenet is > used to create a secure and anonymous environment for communicating. Very cool. I've done that too :-). > One of the issues with freenet is that it is slow. I haven't used it > in many years and do understand it has gotten much better. I also am > aware that after a few days it gets faster as popular data is > retained and gets 'cached' on your node and nearby nodes based on > what those around you are doing. > > What I'm trying to figure out is what happens when your node is not on > 24/7 and you can only connect infrequently for several hours at a > time. It runs at esssentially the same speed (minus the benefits of immediate local caching, of course) -- which is pretty slow but manageable. It may take a few seconds / a minute longer to fetch things, but that's still a minute longer than the censored web provides, so either way users will have to adjust their expectations. Booting into the network will also take an additional minute or so, which always-on nodes don't have to worry about. > Many users have a persistent local threat that they need to be aware > of. Leaving a server running is not an option as it could be > compromised by an adversary. > > Removable media can reduce that threat. The keyword being *reduce* :p. We all have that concern and fear, of unforeseen zero-day linux exploits, etc. (We already know they exist in Window$ :). Ideally you would want to make extra sure you have "enough" contingency planning (proper permissioning / stable and patched software / firewalls / perhaps "caged" virtual machines / "sentry" programs / whatever your paranoia desires), so such fears are minimized. They will never be eliminated though. > What I'm looking to find out is if you run a freenode from a > removable media and then run a local server running freenode to use > as one of your peers (which could be on all the time) does this post > a threat? Besides the obvious risks of either of those machines being compromised (by any number of ways: physically, buggy software, leaky software, etc), traffic analysis will always be a threat with Tor, and also with Freenet if bad guys have somehow managed to occupy all your peer connections. But besides these well known threats, I think it's pretty safe. But not perfectly safe. > If no local server is run that you peer with how is the speed if you > only connect every few days? Is running freenet for a few hours to > several hours going to be sufficient or will it be unbearably slow? It's bearable. (After it takes a few minutes to connect to the network.) I suppose it's similar to fetching a freesite you never fetched before -- perhaps a bit faster. > With Tor speeds are frequently severely limited. Especially > with .onion nodes. Some non-onion servers can be accessed with > significant speed though for sustained periods (15-300... maybe > faster). That's probably not a Tor-specific problem -- but simply the less powerful server behind the onioning. I don't think there are any youtube-sized .onion servers. ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
[freenet-support] Freenet speed & local threats
I am looking into setting up a distribution where Tor or freenet is used to create a secure and anonymous environment for communicating. One of the issues with freenet is that it is slow. I haven't used it in many years and do understand it has gotten much better. I also am aware that after a few days it gets faster as popular data is retained and gets 'cached' on your node and nearby nodes based on what those around you are doing. What I'm trying to figure out is what happens when your node is not on 24/7 and you can only connect infrequently for several hours at a time. Many users have a persistent local threat that they need to be aware of. Leaving a server running is not an option as it could be compromised by an adversary. Removable media can reduce that threat. What I'm looking to find out is if you run a freenode from a removable media and then run a local server running freenode to use as one of your peers (which could be on all the time) does this post a threat? If no local server is run that you peer with how is the speed if you only connect every few days? Is running freenet for a few hours to several hours going to be sufficient or will it be unbearably slow? With Tor speeds are frequently severely limited. Especially with .onion nodes. Some non-onion servers can be accessed with significant speed though for sustained periods (15-300... maybe faster). ___ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
