[freenet-support] "BitTorrent"
> Freenet has a thing called a 'datastore'. Every node (user) of Freenet > dedicates some talking about the datastore, if Freenet hasn't modified its behaviour lately I recall the every stored key is bound to disappear sooner or later from all the datastores. This is good when seen a wise usage of available space, and this is similar to the way bittorrent works (unpopulated torrents eventually are bound to disappear). However this is an undesirable behaviour to those looking for rare stuff. The reason for these ramblings is as follows. In a single week two of my older HDs have started showing signs of death. This is bad. I had to buy bigger a fat new HD to backup the data. Imagine what would happen if a big HD suddenly fails? Personally I don't have the money to buy a tape streamer or to completely mirror my data. Burning DVDs is not a viable option: DVD are prone to fast deterioration as time passes, plus they are remarkably small, compared to a modern Hard Disk. Now, what would happen if key are never bound to expire in a freenet datastore? Then you would have a permanent remote backup of your precious data. A darknet could be made to work as a remarkable distributed and (not so strongly) encrypted multiuser network backup system. If I recall correctly, the datastore size determines when a key is about to expire. Given that I'm willing to dedicate a full encrypted HD as a datastore, I'd like to suggest the possibility of a Freenet branch with the option to disable key expiration and to stop storing keys when the datastore is full. sorry for the dumb request.. bye Inverse
[freenet-chat] Re: [freenet-support] Freenet 0.7
Matthew Toseland wrote: > It's unnecessary anyway because it only applies to TCP. It does however > tell us something very interesting and useful: The firewall is stateless !! heh, it would be damn expensive to do that in a stateful way. let's see: >1. Timing. >2. Packet size. >3. It's not a known protocol, therefore it must be bad. >4. Flow analysis. either way it might be too expensive or require a stateful filter
[freenet-chat] Re: [freenet-support] Freenet 0.7
urza9814 at gmail.com wrote: > Have you thought about that ignoring reset packets thing that was > shown to make it possible to bypass The Great Firewall? I mean, I > don't know too much about it, or if it'd be possible for > freenetbut it might be worth looking in to. it's possible to do it, but only under linux at the moment. You just set an iptables prerouting rule that drops incoming tcp RST packets. This a kernel side level 4 setting that's perfectly transparent to the application level, the only side effect being that any incoming connection will end with a timeout in place of a graceful reset. Under windows I suppose you simply lack the instruments and support to do something clever like that.
[freenet-chat] Re: [freenet-support] Freenet 0.7
David 'Bombe' Roden wrote: > Communication between 0.7 nodes doesn't have to exchange public keys, > those are already known as they are contained in the node reference. nice! I definitely need to install 0.7 and capture some packets for testing
Re: [freenet-chat] Re: [freenet-support] Freenet 0.7
Matthew Toseland wrote: It's unnecessary anyway because it only applies to TCP. It does however tell us something very interesting and useful: The firewall is stateless !! heh, it would be damn expensive to do that in a stateful way. let's see: 1. Timing. 2. Packet size. 3. It's not a known protocol, therefore it must be bad. 4. Flow analysis. either way it might be too expensive or require a stateful filter ___ 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:[EMAIL PROTECTED]
[freenet-chat] Re: [freenet-support] Freenet 0.7
Matthew Toseland wrote: > Well on the most trivial level, 0.5 doesn't work in china. > yo, beyond harvesting the connected IP addresses to raid their owner's homes, one big concern with encrypted protocols is that they can be filtered out by application-level scanning firewalls. I think this is exactly what's happening in China. Application-level scanning can be implemented via ASIC technology directly in hardware thus being extremely fast, and we know this works very well. Public-key encrypted communications show constant patterns the moment a public key is exchanged between hosts. Such system can work until there's enough processing power available to make them run without compromising the overal network performance, so to defeat them (they are intended to simply drop forbidden connections) you have to design a protocol which shows no recognisable patterns at any level. Nested symmetric encryption of each packet with multiple randomly selected pre-shared keys? To decode each packet a firewall will have to: 1) try at least half the known pre-shared keys on each packet 2) do the above for each level of encryption used. given the number of keys n and the number of levels l the total number of decryption passes k before you extract usable data (which may be further asymmetrically encrypted) is k = (n/2)^l. This is true for each packet and you cannot avoid doing this if you want to confirm the contents. While this might not be so demanding for a single CPU and few connections, a core firewall won't be happy to discover that a simple scan no longer suffices and you have to actually process a VERY large number of packets coming from a number of sources with random ports trough a custom designed and frequently updated cryptographic ASIC multiple times. The idea is not to design a virtually unstopplable protocol: there might come a day when only pure HTTP to port 80 is allowed, the idea instead is to make it a bit more unstoppable in places like China, probably France and EU and next in the US. Also, this won't be a solution in places that trace social network connections (like the current US), this however will make the process somewhat harder. Just a suggestion..
Re: [freenet-chat] Re: [freenet-support] Freenet 0.7
Matthew Toseland wrote: Well on the most trivial level, 0.5 doesn't work in china. yo, beyond harvesting the connected IP addresses to raid their owner's homes, one big concern with encrypted protocols is that they can be filtered out by application-level scanning firewalls. I think this is exactly what's happening in China. Application-level scanning can be implemented via ASIC technology directly in hardware thus being extremely fast, and we know this works very well. Public-key encrypted communications show constant patterns the moment a public key is exchanged between hosts. Such system can work until there's enough processing power available to make them run without compromising the overal network performance, so to defeat them (they are intended to simply drop forbidden connections) you have to design a protocol which shows no recognisable patterns at any level. Nested symmetric encryption of each packet with multiple randomly selected pre-shared keys? To decode each packet a firewall will have to: 1) try at least half the known pre-shared keys on each packet 2) do the above for each level of encryption used. given the number of keys n and the number of levels l the total number of decryption passes k before you extract usable data (which may be further asymmetrically encrypted) is k = (n/2)^l. This is true for each packet and you cannot avoid doing this if you want to confirm the contents. While this might not be so demanding for a single CPU and few connections, a core firewall won't be happy to discover that a simple scan no longer suffices and you have to actually process a VERY large number of packets coming from a number of sources with random ports trough a custom designed and frequently updated cryptographic ASIC multiple times. The idea is not to design a virtually unstopplable protocol: there might come a day when only pure HTTP to port 80 is allowed, the idea instead is to make it a bit more unstoppable in places like China, probably France and EU and next in the US. Also, this won't be a solution in places that trace social network connections (like the current US), this however will make the process somewhat harder. Just a suggestion.. ___ 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:[EMAIL PROTECTED]
Re: [freenet-chat] Re: [freenet-support] Freenet 0.7
David 'Bombe' Roden wrote: Communication between 0.7 nodes doesn't have to exchange public keys, those are already known as they are contained in the node reference. nice! I definitely need to install 0.7 and capture some packets for testing ___ 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:[EMAIL PROTECTED]
Re: [freenet-chat] Re: [freenet-support] Freenet 0.7
[EMAIL PROTECTED] wrote: Have you thought about that ignoring reset packets thing that was shown to make it possible to bypass The Great Firewall? I mean, I don't know too much about it, or if it'd be possible for freenetbut it might be worth looking in to. it's possible to do it, but only under linux at the moment. You just set an iptables prerouting rule that drops incoming tcp RST packets. This a kernel side level 4 setting that's perfectly transparent to the application level, the only side effect being that any incoming connection will end with a timeout in place of a graceful reset. Under windows I suppose you simply lack the instruments and support to do something clever like that. ___ 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:[EMAIL PROTECTED]
[freenet-support] Freenet 0,5 and 0,7
nobody at geonosis.homelinux.net wrote: > Please, Do NOT suggest switching to Linux, I've tried it and my hardware will > not support it's demands. Again, this is a matter of money that unlike SOME > people, I don't have a hell > I suggest linux. There are many versions of it, some of them designed to run on very poor hardware with insufficient ram. Money is not an excuse for using a bad OS. Just look for a minimalist linux. There are many good window managers like IceWM (IIRC) which won't demand much memory.
Re: [freenet-support] Freenet 0,5 and 0,7
[EMAIL PROTECTED] wrote: Please, Do NOT suggest switching to Linux, I've tried it and my hardware will not support it's demands. Again, this is a matter of money that unlike SOME people, I don't have a hell I suggest linux. There are many versions of it, some of them designed to run on very poor hardware with insufficient ram. Money is not an excuse for using a bad OS. Just look for a minimalist linux. There are many good window managers like IceWM (IIRC) which won't demand much memory. ___ 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:[EMAIL PROTECTED]
Re: [freenet-support] datastore out of control
5tucatz elPunishar wrote: is there anything i can do ? i already tried deleting the datastore.. doesn't help. amazing. Looks like your HD got datastore-cancer. It's gonna explode, no matter what you can do. ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
Re: [freenet-support] Fw: LoveGangs relations to see !
Moro Beatrice wrote: Moro Beatrice? Buy yourself a better antivirus software. ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
Re: [freenet-support]
MA wrote: ÄúºÃ£º ÖйúÈË£¿ ___ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
