Re: [freenet-dev] Tunnels was Re: Project Status
Am Sonntag, 18. Oktober 2015, 14:33:53 schrieb salutarydiacritica...@ruggedinbox.com: > I can't see the new page because of unauthorized error. The error message gives you the login. (guest / guest) — it’s just for locking out bots. > Some of the papers are on anonbib but many are not. I’m not sure about their copyright status. A few are from 2000, where open access was virtually unknown > You can try the National Science Foundation or something like it in your > country for funding proposals. That’s a pretty heavy process and I’m not sure we’re up for it, else we’d already be doing it. That’s why I asked for things regular people can do. Best wishes, Arne -- Celebrate with ye beauty and gather yer friends for a Pirate Party! → http://1w6.org/english/flyerbook-rules#pirate-party ← signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
Am Montag, 19. Oktober 2015, 01:16:24 schrieb salutarydiacritica...@ruggedinbox.com: > You might want to look into maintaining a subreddit and other social > media accounts. Its a way to reach more people. > > Reddit fundraising was a big success last year with tens of thousands of > dollars for privacy projects. Reddit already shadowbanned some Freenet supporters for giving technical information about Freenet (for example me). If you want to try to revitalize /r/freenet, please go for it. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
Am Sonntag, 18. Oktober 2015, 20:54:33 schrieb Matthew Toseland: > Multi-sourcing does not improve anonymity - it tends to reduce it. It allows using higher latency without impacting the user experience. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
On 19/10/15 07:23, Arne Babenhauserheide wrote: > Am Sonntag, 18. Oktober 2015, 20:54:33 schrieb Matthew Toseland: >> Multi-sourcing does not improve anonymity - it tends to reduce it. > It allows using higher latency without impacting the user experience. It also gives the attacker more samples. IMHO high latency means "fire and forget" tunnels for inserts, which can happily have multi-hour latency. For requests we generally need a quick response. Or at least, implementing long-term requests would be significantly harder. It might be interesting though on darknet. > Best wishes, > Arne signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
On 18/10/15 10:03, Arne Babenhauserheide wrote: > Am Sonntag, 18. Oktober 2015, 01:47:05 schrieb > salutarydiacritica...@ruggedinbox.com: >> Adding latency is a bad idea and actually less effective than you >> believe compared to other ways. >> >> http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf > As far as I can see by quick skimming, this is only about interactive > use of centralized services. “Latency is prohibitive” applies to a > much lower degree if the local service can do significant prefetching, > and if you can get stuff in massively parallel ways (like getting 20 > chunks of a 400 kiB file simultaneously from 20 different sources > using 20 different routes). Multi-sourcing does not improve anonymity - it tends to reduce it. The point here is that *for some use cases*, where latency can be tolerated, Mixminion-style mixes work well. These cases include email (for some uses anyway) and big Freenet inserts (at least on darknet), where it will take a day or so anyway so delaying the insert isn't a big deal. Mixes are similar to onion routing but they are actual mixes - some number of messages go in and the same number go out, in some fixed time period. This gives them provable properties against traffic analysis. However I will have a look at the paper when I have time. >> Slowing down the network pushes away users and less trees in the forest >> degrades anonymity. >> >> See above. Which is a good reason to not multiply the hop count by 6, as you are proposing, by hiding *every* node behind a hidden service. I agree that it might make sense at some point to support optionally using Tor for initiating requests. If we were going to build something on top of a mixnet, it wouldn't be Freenet. You'd want a very shallow DHT - maybe even 1-hop - and to return data directly to the requestor, for large enough requests (probably increasing the block size to make this cheaper). But feel free to fork our client layer and replace the routing and connection levels. >> Freenet should move to secure crypto primitives right now. DH 1024 is >> dead and SHA1 should not be used for jar verification. > This is already happening. Why do we use SHA1 for Jar verification? Is this a JDK1.6 limitation? Nothing in Freenet itself uses SHA1. And yes, we need ECC-based SSKs. This has been discussed, there are bugs for it. There isn't funding for it right now. >> Are Freenet's papers on freehaven.net? > If not, it would be great if you could get them there: > https://freenetproject.org/papers.html?language=en > >> For funding you should include as many payment methods as you can to >> make donations convenient. Your new frontpage should include a >> fundraising bar for year base costs. Then you say for any extra money >> you direct users to a detailed roadmap for planned Freenet features with >> estimates for manhour costs to develop. A visual representation >> motivates donators and makes them feel they are giving money towards >> something defined. > What do you think about the donation bar on > https://testing.freenetproject.org? In general I agree, however IMHO we need people for base costs. Servers and accounts are cheap. But we can't spend money developing huge changes which then can't be merged because the volunteer release manager(s) don't have time to review them. And there will often be things that need doing quickly, or that aren't obviously important to donors. So I'm very sceptical about bounties. >> Go for research grants if you can and try talking at >> universities and privacy conferences to recruit researchers. > I applied at opentech.fund, but I can’t predict whether it will work > out. The CENO folks applied for a grant at another position, too, > which should include work from freenet developers, if they do get the > grant. If you have other places where people with limited experience > in running on grants can apply, please note them here. Agreed we should apply for grants. However in the more specific academic sense, research grants are important because they result in papers that occasionally have something we can deploy - last year we implemented simple but hugely important changes to opennet based on a published paper. What research grants don't do is result in usable code. We need to look at more general funding options, and I absolutely agree that we need more academic attention - but in recent years we seem to be getting it, which is great. If we're lucky, my academic project this year will fix load management. We've done a huge amount of work since 0.7.5. Why don't we try the traditional approach of releasing 0.8.0, getting some publicity and asking for donations? > Best wishes, > Arne signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
You might want to look into maintaining a subreddit and other social media accounts. Its a way to reach more people. Reddit fundraising was a big success last year with tens of thousands of dollars for privacy projects. On 2015-10-18 15:54, Matthew Toseland wrote: On 18/10/15 10:03, Arne Babenhauserheide wrote: Am Sonntag, 18. Oktober 2015, 01:47:05 schrieb salutarydiacritica...@ruggedinbox.com: Adding latency is a bad idea and actually less effective than you believe compared to other ways. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf As far as I can see by quick skimming, this is only about interactive use of centralized services. “Latency is prohibitive” applies to a much lower degree if the local service can do significant prefetching, and if you can get stuff in massively parallel ways (like getting 20 chunks of a 400 kiB file simultaneously from 20 different sources using 20 different routes). Multi-sourcing does not improve anonymity - it tends to reduce it. The point here is that *for some use cases*, where latency can be tolerated, Mixminion-style mixes work well. These cases include email (for some uses anyway) and big Freenet inserts (at least on darknet), where it will take a day or so anyway so delaying the insert isn't a big deal. Mixes are similar to onion routing but they are actual mixes - some number of messages go in and the same number go out, in some fixed time period. This gives them provable properties against traffic analysis. However I will have a look at the paper when I have time. Slowing down the network pushes away users and less trees in the forest degrades anonymity. See above. Which is a good reason to not multiply the hop count by 6, as you are proposing, by hiding *every* node behind a hidden service. I agree that it might make sense at some point to support optionally using Tor for initiating requests. If we were going to build something on top of a mixnet, it wouldn't be Freenet. You'd want a very shallow DHT - maybe even 1-hop - and to return data directly to the requestor, for large enough requests (probably increasing the block size to make this cheaper). But feel free to fork our client layer and replace the routing and connection levels. Freenet should move to secure crypto primitives right now. DH 1024 is dead and SHA1 should not be used for jar verification. This is already happening. Why do we use SHA1 for Jar verification? Is this a JDK1.6 limitation? Nothing in Freenet itself uses SHA1. And yes, we need ECC-based SSKs. This has been discussed, there are bugs for it. There isn't funding for it right now. Are Freenet's papers on freehaven.net? If not, it would be great if you could get them there: https://freenetproject.org/papers.html?language=en For funding you should include as many payment methods as you can to make donations convenient. Your new frontpage should include a fundraising bar for year base costs. Then you say for any extra money you direct users to a detailed roadmap for planned Freenet features with estimates for manhour costs to develop. A visual representation motivates donators and makes them feel they are giving money towards something defined. What do you think about the donation bar on https://testing.freenetproject.org? In general I agree, however IMHO we need people for base costs. Servers and accounts are cheap. But we can't spend money developing huge changes which then can't be merged because the volunteer release manager(s) don't have time to review them. And there will often be things that need doing quickly, or that aren't obviously important to donors. So I'm very sceptical about bounties. Go for research grants if you can and try talking at universities and privacy conferences to recruit researchers. I applied at opentech.fund, but I can’t predict whether it will work out. The CENO folks applied for a grant at another position, too, which should include work from freenet developers, if they do get the grant. If you have other places where people with limited experience in running on grants can apply, please note them here. Agreed we should apply for grants. However in the more specific academic sense, research grants are important because they result in papers that occasionally have something we can deploy - last year we implemented simple but hugely important changes to opennet based on a published paper. What research grants don't do is result in usable code. We need to look at more general funding options, and I absolutely agree that we need more academic attention - but in recent years we seem to be getting it, which is great. If we're lucky, my academic project this year will fix load management. We've done a huge amount of work since 0.7.5. Why don't we try the traditional approach of releasing 0.8.0, getting some publicity and asking for donations? Best wishes, Arne ___ Devl mailing list Devl@freenetproject.org
Re: [freenet-dev] Tunnels was Re: Project Status
I can't see the new page because of unauthorized error. Some of the papers are on anonbib but many are not. You can try the National Science Foundation or something like it in your country for funding proposals. On 2015-10-18 05:03, Arne Babenhauserheide wrote: Am Sonntag, 18. Oktober 2015, 01:47:05 schrieb salutarydiacritica...@ruggedinbox.com: Adding latency is a bad idea and actually less effective than you believe compared to other ways. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf As far as I can see by quick skimming, this is only about interactive use of centralized services. “Latency is prohibitive” applies to a much lower degree if the local service can do significant prefetching, and if you can get stuff in massively parallel ways (like getting 20 chunks of a 400 kiB file simultaneously from 20 different sources using 20 different routes). Slowing down the network pushes away users and less trees in the forest degrades anonymity. See above. Freenet should move to secure crypto primitives right now. DH 1024 is dead and SHA1 should not be used for jar verification. This is already happening. Are Freenet's papers on freehaven.net? If not, it would be great if you could get them there: https://freenetproject.org/papers.html?language=en For funding you should include as many payment methods as you can to make donations convenient. Your new frontpage should include a fundraising bar for year base costs. Then you say for any extra money you direct users to a detailed roadmap for planned Freenet features with estimates for manhour costs to develop. A visual representation motivates donators and makes them feel they are giving money towards something defined. What do you think about the donation bar on https://testing.freenetproject.org? Go for research grants if you can and try talking at universities and privacy conferences to recruit researchers. I applied at opentech.fund, but I can’t predict whether it will work out. The CENO folks applied for a grant at another position, too, which should include work from freenet developers, if they do get the grant. If you have other places where people with limited experience in running on grants can apply, please note them here. Best wishes, Arne ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
Am Sonntag, 18. Oktober 2015, 01:47:05 schrieb salutarydiacritica...@ruggedinbox.com: > Adding latency is a bad idea and actually less effective than you > believe compared to other ways. > > http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf As far as I can see by quick skimming, this is only about interactive use of centralized services. “Latency is prohibitive” applies to a much lower degree if the local service can do significant prefetching, and if you can get stuff in massively parallel ways (like getting 20 chunks of a 400 kiB file simultaneously from 20 different sources using 20 different routes). > Slowing down the network pushes away users and less trees in the forest > degrades anonymity. See above. > Freenet should move to secure crypto primitives right now. DH 1024 is > dead and SHA1 should not be used for jar verification. This is already happening. > Are Freenet's papers on freehaven.net? If not, it would be great if you could get them there: https://freenetproject.org/papers.html?language=en > For funding you should include as many payment methods as you can to > make donations convenient. Your new frontpage should include a > fundraising bar for year base costs. Then you say for any extra money > you direct users to a detailed roadmap for planned Freenet features with > estimates for manhour costs to develop. A visual representation > motivates donators and makes them feel they are giving money towards > something defined. What do you think about the donation bar on https://testing.freenetproject.org? > Go for research grants if you can and try talking at > universities and privacy conferences to recruit researchers. I applied at opentech.fund, but I can’t predict whether it will work out. The CENO folks applied for a grant at another position, too, which should include work from freenet developers, if they do get the grant. If you have other places where people with limited experience in running on grants can apply, please note them here. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
Am Samstag, 17. Oktober 2015, 23:35:31 schrieb Matthew Toseland: > > Also Freenet-over-wireless would kill traffic analysis. > As I mentioned before, you still need the long links. If it's mostly > wireless, and the long links don't connect directly to each other, and > you have some credible stego ... then maybe. It depends on how > determined your opponent is though. Wireless has limited capacity, > especially if you're not building relatively expensive, easier to > detect, possibly illegal, directional infrastructure links. Let’s stop thinking problems we’re very far from tackling and start thinking about things we can already do to improve Freenet. When we actually hit that point, we’ll find solutions. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
On 17/10/15 22:31, Arne Babenhauserheide wrote: > Am Samstag, 17. Oktober 2015, 21:04:23 schrieb Matthew Toseland: I do think we could provide better anonymity than Tor in the long run though. But we can't prevent blocking - *any* peer-to-peer network running over the regular Internet can be detected cheaply. >>> Even when Freenet integrates steganography features? >> Yes. Traffic flow analysis can identify p2p networks by looking at the >> topology of the connections - even if the traffic looks like e.g. HTTPS. > Not if we’re willing to pay with high latency and only exchange data > when people actually call each other with video-telephony or run their > game client with mumble-chat. Then you get into hard stego. The catch is dealing with that sort of latency is hard, even if it's acceptable to the user (which it probably isn't) ... and worse, it radically cuts your bandwidth. > Also Freenet-over-wireless would kill traffic analysis. As I mentioned before, you still need the long links. If it's mostly wireless, and the long links don't connect directly to each other, and you have some credible stego ... then maybe. It depends on how determined your opponent is though. Wireless has limited capacity, especially if you're not building relatively expensive, easier to detect, possibly illegal, directional infrastructure links. > Best wishes, > Arne signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
They frown on bittorrent yes but because it takes up limited exit bandwidth. Theoretically Freenet is contained in the network and not exiting. Recent statistics Tor put out say only 3% of total network bandwidth goes to hidden service traffic, very underused. Total connection is 6 hops but the latency is in ms and won't be the bottleneck for Freenet. They are planning a extra mode that hides clients but not the service only 3 hops. Tor can be told to authenticate connections to a hidden service and anyone without a generated pass code won't get in. Maybe good for Darknet. They are also replacing AES-CBC with AEZ for performance and stopping cell tampering. https://lists.torproject.org/pipermail/tor-dev/2015-October/009684.html Tor bridges work for hundred of thousands of users from Iran and China so they are doing something right. Sybil doesn't always win if you raise costs. Syndie doesn't do the distributing they recommend you for that :) @Arne Adding latency is a bad idea and actually less effective than you believe compared to other ways. http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf Slowing down the network pushes away users and less trees in the forest degrades anonymity. Freenet should move to secure crypto primitives right now. DH 1024 is dead and SHA1 should not be used for jar verification. Are Freenet's papers on freehaven.net? For funding you should include as many payment methods as you can to make donations convenient. Your new frontpage should include a fundraising bar for year base costs. Then you say for any extra money you direct users to a detailed roadmap for planned Freenet features with estimates for manhour costs to develop. A visual representation motivates donators and makes them feel they are giving money towards something defined. Go for research grants if you can and try talking at universities and privacy conferences to recruit researchers. On 2015-10-17 18:41, Matthew Toseland wrote: On 17/10/15 01:33, salutarydiacritica...@ruggedinbox.com wrote: Right now Freenet discovers other clients on opennet by way of seed nodes. Hypothetically you can run the nodes as hidden services and embed the addresses in Freenet clients. Clients generate their own hidden address keys and build routing tables from them. I don't think hiding entire nodes behind tunnels makes sense. That is, we don't want *every hop* on a hidden service. That would multiply the number of hops by 4 (or was it 6?). And it would upset the Tor developers - who already frown on the use of Bittorrent over Tor (which is surprisingly hard to get right regardless). However, it might make sense to use a tunnel *just on the first hop* when starting a request, i.e. keep some subset of connections which are hidden nodes to start requests on. However, IMHO the focus for security should be on darknet, at least until we sort out the major performance and usability issues with it. Even if you DO know other people on Freenet, darknet is too slow and too hard. No distributed system on I2P or Tor comes close to Freenet features. Have you used them? I vaguely recall something called Syndie on I2P? WoT, library, the plugin ecosystem and Opennet bring a lot of value compared to other systems. Opennet is a big part of Freenet's attraction and you shouldn't tear it out. I'm certainly not proposing to tear out opennet. The tunneling idea sounds great and it should get priority. Maybe you should discuss it with the Tor developers and see if they can help. PS what NSA documents mention contractors attacking Freenet? I don't recall, was it on the Tor Stinks intro?? @Ian Freenet has many selling points besides anonymity as I said. I'm surprised you don't see that. Tor is not easily blocked by China and people connect from behind the Great Firewall everyday. They've been making all kinds of advancements in bridge technology and obfuscated protocols to bypass DPI. They have ways to distribute bridges and software packages that get around censorship of their website. Infrastructure for your users potentially. Not true now AFAIK. China has been taking Tor seriously, so has Iran. China came up with a 0day and used it for blocking at the protocol level, but really, it's pretty easy to find all the bridges, it just costs a few thousand Google accounts, which cost << 10 cents each. If users can find the bridges then so can the bad guys, and cheaply too. This is a fundamental problem with all end-user distributed systems on the internet: Sybil always wins, because any resource (CAPTCHAs, Google Phone Verified Accounts, hashcash, etc) is cheaper for an attacker than a low-end user. @Arne I am a Freenet user. I care about Freenet and want it to be popular with people facing most dangerous threats. Tor is adding inter-relay adaptive padding soon to stop timing attacks. That would be neat. For many years it was believed that only full CBR would make much difference against
Re: [freenet-dev] Tunnels was Re: Project Status
From: Matthew Toseland <mj...@cam.ac.uk> Date: 17.10.2015 18:41:23 At: devl@freenetproject.org Topic: [freenet-dev] Tunnels was Re: Project Status > I do think we could provide better anonymity than Tor in the long run > though. But we can't prevent blocking - *any* peer-to-peer network > running over the regular Internet can be detected cheaply. Even when Freenet integrates steganography features? ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
On 17/10/15 20:45, hyazin...@emailn.de wrote: > From: Matthew Toseland <mj...@cam.ac.uk> > Date: 17.10.2015 18:41:23 > At: devl@freenetproject.org > Topic: [freenet-dev] Tunnels was Re: Project Status >> I do think we could provide better anonymity than Tor in the long run >> though. But we can't prevent blocking - *any* peer-to-peer network >> running over the regular Internet can be detected cheaply. > Even when Freenet integrates steganography features? Yes. Traffic flow analysis can identify p2p networks by looking at the topology of the connections - even if the traffic looks like e.g. HTTPS. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
[freenet-dev] Tunnels was Re: Project Status
On 17/10/15 01:33, salutarydiacritica...@ruggedinbox.com wrote: > Right now Freenet discovers other clients on opennet by way of seed > nodes. Hypothetically you can run the nodes as hidden services and > embed the addresses in Freenet clients. Clients generate their own > hidden address keys and build routing tables from them. I don't think hiding entire nodes behind tunnels makes sense. That is, we don't want *every hop* on a hidden service. That would multiply the number of hops by 4 (or was it 6?). And it would upset the Tor developers - who already frown on the use of Bittorrent over Tor (which is surprisingly hard to get right regardless). However, it might make sense to use a tunnel *just on the first hop* when starting a request, i.e. keep some subset of connections which are hidden nodes to start requests on. However, IMHO the focus for security should be on darknet, at least until we sort out the major performance and usability issues with it. Even if you DO know other people on Freenet, darknet is too slow and too hard. > No distributed system on I2P or Tor comes close to Freenet features. Have you used them? I vaguely recall something called Syndie on I2P? > WoT, library, the plugin ecosystem and Opennet bring a lot of value > compared to other systems. Opennet is a big part of Freenet's > attraction and you shouldn't tear it out. I'm certainly not proposing to tear out opennet. > The tunneling idea sounds great and it should get priority. Maybe you > should discuss it with the Tor developers and see if they can help. > > PS what NSA documents mention contractors attacking Freenet? I don't recall, was it on the Tor Stinks intro?? > > > > @Ian > > Freenet has many selling points besides anonymity as I said. I'm > surprised you don't see that. > > Tor is not easily blocked by China and people connect from behind the > Great Firewall everyday. They've been making all kinds of advancements > in bridge technology and obfuscated protocols to bypass DPI. They have > ways to distribute bridges and software packages that get around > censorship of their website. Infrastructure for your users potentially. Not true now AFAIK. China has been taking Tor seriously, so has Iran. China came up with a 0day and used it for blocking at the protocol level, but really, it's pretty easy to find all the bridges, it just costs a few thousand Google accounts, which cost << 10 cents each. If users can find the bridges then so can the bad guys, and cheaply too. This is a fundamental problem with all end-user distributed systems on the internet: Sybil always wins, because any resource (CAPTCHAs, Google Phone Verified Accounts, hashcash, etc) is cheaper for an attacker than a low-end user. > @Arne > > I am a Freenet user. I care about Freenet and want it to be popular > with people facing most dangerous threats. > > Tor is adding inter-relay adaptive padding soon to stop timing attacks. That would be neat. For many years it was believed that only full CBR would make much difference against global traffic analysis - and even then you have internal attacks. I understand there have been some recent papers about padding and chaff etc that make significant progress without the cost of full CBR. However, on Freenet, we could reasonably use Mixminion-style high-latency tunnels (at least for inserts). It's not clear whether this is viable on opennet. > https://lists.torproject.org/pipermail/tor-dev/2015-September/009485.html > > > How did Freenet solve this? If a bad node can connect to you on > Opennet, they can do traffic analysis on your requests. With no guard > nodes an attacker can connect to everyone in short time. You can add > node pinning and tunnels but that's a lot of work. We don't solve it. Freenet provides less anonymity than Tor right now - at least in opennet mode, and depending on your assumptions. On the other hand, running a freesite is easier than safely running a hidden service. In particular, connecting to every node on opennet and observing their traffic is quite feasible for a moderately funded attacker. On the other hand, it appears that MAST (a theoretical, much cheaper attack that worried me for many years) isn't feasible. I do think we could provide better anonymity than Tor in the long run though. But we can't prevent blocking - *any* peer-to-peer network running over the regular Internet can be detected cheaply. signature.asc Description: OpenPGP digital signature ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
Re: [freenet-dev] Tunnels was Re: Project Status
Am Samstag, 17. Oktober 2015, 21:04:23 schrieb Matthew Toseland: > >> I do think we could provide better anonymity than Tor in the long run > >> though. But we can't prevent blocking - *any* peer-to-peer network > >> running over the regular Internet can be detected cheaply. > > Even when Freenet integrates steganography features? > Yes. Traffic flow analysis can identify p2p networks by looking at the > topology of the connections - even if the traffic looks like e.g. HTTPS. Not if we’re willing to pay with high latency and only exchange data when people actually call each other with video-telephony or run their game client with mumble-chat. Also Freenet-over-wireless would kill traffic analysis. Best wishes, Arne signature.asc Description: This is a digitally signed message part. ___ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
