On Tuesday 06 January 2009 16:51, 3BUIb3S50i 3BUIb3S50i wrote: > So, Freemulet or Frost "automatic insertion" are dangerous? We know the key > before the upload of the file.
Yes IMHO. > > > On Mon, Jan 5, 2009 at 5:29 PM, Matthew Toseland > <toad at amphibian.dyndns.org>wrote: > > > On Tuesday 23 December 2008 18:14, Shironeko wrote: > > > Dear Freenet Support Team, > > > > > > I send you this message because I've stumbled upon a "curiosity" which > > I'd > > > like to get explained since I'm not able to find any other documentation > > > regarding this issue. > > > > > > I was browsing through my hard drive's Freenet Directory, looking at the > > > latest logs when I suddenly realized that there were IP adresses written > > in. > > > > > > This is an example: > > > > > > dic 23, 2008 17:06:14:078 (freenet.node.NodeDispatcher, UdpSocketHandler > > for > > > port 266XX(2), NORMAL): Rejecting CHK request from 213.238.213.XX:387XX > > > preemptively because Insufficient output bandwidth > > > > > > I may not fully understand the protocol Freenet uses for data > > transmission > > > but these IP's are uplookable and can represent a problem for anyone who > > > connects from a country like China. > > > > I don't see why. For it to be a problem the bad guys would have to already > > have seized (or electronically compromised) your node, in which case they > > probably have your browser history, your datastore, your Friends list ... > > > > > > Also, I wonder if it would be possible to collect valuable information by > > > gathering the LOGs of many different nodes and following a specific IP's > > > requests. > > > > Yes, but you'd need to compromise all the nodes on the path of that > > request. > > > > > > Finally I'd like to ask you about this message I found in the logs too: > > > > > > "Note that this version of Freenet is still a very early alpha, and may > > well > > > have numerous bugs and design flaws. > > > In particular: YOU ARE WIDE OPEN TO YOUR IMMEDIATE PEERS! They can > > eavesdrop > > > on your requests with relatively little difficulty at present > > (correlation > > > attacks etc)." > > > > > > I suppose that this must be an old message since the Freenet project is > > not > > > in a very early alpha version anymore and I'm using 0.7, the latest. > > > > This is partly true. There are a number of known attacks on Freenet, which > > cannot be completely eliminated short of new features which we have not yet > > implemented. On the other hand, for some situations, Freenet may be the > > best > > currently available. For example, Freenet's scalable darknet functionality > > is > > fairly unusual, allowing you to only connect to people you trust, and also > > it > > is easier to safely publish a website on Freenet than on a Tor hidden > > service > > afaik (due to e.g. issues with configuring apache to not give away > > incriminating details, and much harder intersection attacks). The bottom > > line > > is if you are going to stake your freedom and/or life on the security of an > > anonymous network, you need to seriously consider the pro's and con's of > > each > > possible option, including doing nothing; Freenet has had severe bugs in > > the > > past, and is pre-1.0, but apart from that, we have fairly serious known > > attacks... > > > > There are 4 basic powerful attacks on Freenet that we are concerned about: > > 1. Harvesting. Finding lots of Freenet nodes quickly, in order to e.g. > > block > > them on a national firewall. Most anonymous networks do not address this > > problem at all. On opennet, harvesting is relatively easy (slightly harder > > than on Tor or I2P); on darknet, harvesting should be fairly hard. > > 2. Datastore seizure. What happens when/if the bad guys either > > electronically > > compromise or physically seize your computer? At the moment everything you > > download through Freenet is cached in your datastore. Temporary files are > > encrypted with ephemeral keys, but for long-term downloads we have to store > > the keys to disk. > > 3. Snooping on your peers. It is probably possible, under some assumptions > > (e.g. being able to identify the content, it being sufficiently large), to > > do > > statistical attacks to figure out what those nodes you are connected to are > > downloading/uploading. This is yet another reason to use darknet. > > 4. Mobile attacker tracing the source of a stream of content. If an > > anonymous > > identity publishes data that can be identified (e.g. reinserting known > > content, posting to FMS boards, posting to a known freesite), it may be > > possible to gradually approach his location. Reinsertion of known content > > makes this much easier, because of CHKs; because we always insert the top > > block (the freesite USK e.g.) last, if the content isn't guessable in > > advance > > it is very difficult to pull this off against large inserts, because the > > attacker can only identify the stream after the top block (or the FMS post > > referring to the new file) was inserted; if the content *is* guessable, the > > attacker can move towards the target continually over the course of the > > insert. > > > > All of these attacks we have some mitigation against, but all of them are > > feasible to some extent under some mostly-reasonable assumptions. Later > > versions of Freenet will make them much harder with new features e.g. > > rendezvous tunnels. > > > > > > Thank you very much. > > > > > > Shiro. > > > > > > PD. I also wonder where the cached and encrypted files on my HD are > > > gathering. > > > > In the freenet directory, generally speaking. > > > > _______________________________________________ > > Support mailing list > > Support at freenetproject.org > > http://news.gmane.org/gmane.network.freenet.support > > Unsubscribe at > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > > Or mailto:support-request at freenetproject.org?subject=unsubscribe > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/support/attachments/20090106/2bbf1af1/attachment.pgp>
