On 30/03/14 18:00, Steve Dougherty wrote: > On 03/22/2014 05:08 PM, Matthew Toseland wrote: >> On 22/03/14 14:13, Tom Sparks wrote: >>>> On Friday, 21 March 2014 9:55 PM, Matthew Toseland >>>> <[email protected]> wrote: >>>>> On 21/03/14 04:42, Steve Dougherty wrote: >>>>> On Tuesday - March 25th - I have a meeting scheduled with Professor J. >>>>> Alex Halderman [0] to talk about security and Freenet. He is one of the >>>>> people behind such research as Green Dam arbitrary code execution, [1] >>>>> cold boot attacks on disk encryption, [2] and insufficient entropy on >>>>> embedded systems leading to weak encryption keys. [3] >>>> Nice. >>>>> What should I say? I'm planning to mention: >>>> Bear in mind that nobody, no matter how brilliant, is an expert in >>>> everything. >>> that I do agree with >> [snip] > They asked more questions about the algorithms and techniques Freenet > uses than I expected. I did demonstrate Sone and mentioned its and > FLIP's latency. > > Some things they asked (that I remember and) think would be good to send > clarification about: > > * Does Freenet use padding? > > I said I thought it does. Does it just pad out packets or also send > empty traffic? We pad blocks and packets. We don't do full blown CBR or chaff at present. That sort of thing should be possible for darknet. Actually it was part of my proposal for opennet modifications if you read carefully. :) (It imposes a bandwidth cost for *remaining* a core opennet node) > * How does Freenet protect against correlation attacks and probing for > which stores / caches contain blocks? > > My answer was that directly connected malicious peers are outside the > threat model, and that probabilistic decrement and lack of knowledge of > network topology beyond the peer's peers make determining these things > difficult. Admittedly this is easier (and becomes MAST?) if you allow > attackers making new connections closer to the target. If you are directly connected you can do a correlation attack; on darknet we can legitimately say this is out of threat model, since your friends are trustworthy (at least more than your opennet peers). A few hops away a correlation attack may still be possible if you know or can deduce the topology; this has not been quantified. However MAST is devastating, as I have explained. We're working towards implementing tunnels that will solve both correlation attacks and MAST. On darknet these should be significantly stronger than Tor is today, due to using social context (PISCES) and exploiting the fact that inserts don't necessarily have to be realtime. (Think mixmaster delays)
Probing datastores is largely pointless: - If you are probing a node which you are directly connected to (with minimum HTL), it could be relayed and propagate the data. - If you are trying to find a node which holds the data in order to kill it, it will certainly be relayed further in the process, so again, the attack isn't very powerful on opennet. This was in the original freenet paper, and is still true; the key thing is you can't find out where data is without propagating it further. > * What are the countermeasures against a node inserting bulk quantities > of junk to get blocks to fall out? This is in the FAQ. On opennet, if the attacker is inserting through one node and requesting through another, the two will gradually converge. On darknet the attacker probably has a limited number of connections. On all nodes we have per-link limits associated with load management, which help a bit. A targeted but remote attack against a specific keyspace location might be slow because of such limits (and you have to reverse some hashes so there is a CPU cost, admittedly limited). > I mentioned that I'd expect one's peers to back off if one was > continually inserting, but I wasn't sure how that (is it load > balancing?) worked. Yes, load management will prefer your other peers if you spam too much IIRC. You will however get some bandwidth. It comes down to bandwidth and connections ultimately. On opennet you can get lots of connections if you're prepared to spend bandwidth and CPU, and you can do bad DoS'es (not to mention surveillance attacks).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
