On 29/03/14 14:20, adilson_lanpo@8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote:> On Sat, 29 Mar 2014 12:10:28 -0000 > Groov@cNcXSeDF4A50Li~bkQ4fplMQHJwa2NEvYOH42Ml8Hlk wrote: > >> adilson_lanpo@8AEGotJKXJ4ABJy1gKjls4SrrzpshQNoEMAbu0IFA94 wrote : >> >>> The NSA would be able to afford to pay so it isn't going to stop >>> them (and if you try to keep out nodes deemed 'excessively' slow I >>> suspect you'll end up eliminating most of the nodes and only end up >>> centralizing freenet to a high bandwidth cabel). >>> >>> If opennet node creation is to be affordable to average people then >>> Sybil attacks must be affordable for pretty much any intelligence >>> agency on the planet. >>> >>> No, it just hopefully restricts them to government, large >>> corporations and rich people who want to spy on Freenet. >>> >> It won't stop the NSA, sure, but then again, suggestions are welcome >> on what would stop the NSA. >> >> This is more about making attacks less feasible for the average >> script kiddie. > > But it might actually be possible to be safe from the average script > kiddie without needing to do such things, we may already be (assuming > there are no scripts out there to automate it, script kiddies aren't > computer literate).
Yes, that's why I use "bored student" rather than "script kiddie" nowadays. However if the bored student publishes the software - which is likely - then it becomes a script kiddie attack. Can we be safe against MAST without taking drastic steps? Good question. See e.g. the bugs from https://bugs.freenetproject.org/view.php?id=217 and https://bugs.freenetproject.org/view.php?id=4577 and the wiki/faq. There are three basic approaches: 1. Try to prevent the attacker from reaching the originator before the insert finishes. Don't route high HTL requests to "young" nodes. (bug #3633) - Only works for short-lived inserts. Doesn't help with e.g. forum posts. - May have implications for routing. Burst inserts - Hard on opennet; mass storage, so need trust or get DoS attacks. 2. Make announcing to a chosen location hard. I.e. impose a cost on opennet identity creation. Note that these has no runtime performance cost, though it may add a few seconds after a restart; most of them inconvenience new users however. Also, it should reduce the potential for e.g. announcement DoS's and other hard to detect dirty tricks. CAPTCHA based identity creation - Might work against script kiddies, no serious deterrent to anyone else. I.e. it doesn't solve Sybil, it makes it cost ~ $2 more per 1000 nodes. - TODO RESEARCH What is the minimum order size and current pricing for the Russian CAPTCHA cracking companies?). - Might be useful if combined with e.g. random routing? IP address based identity creation and announcement - Relatively complex, centralise opennet a bit (especially if we want to ensure that one IP is only used for one node at a time). - Limited security gains. - TODO RESEARCH What does a unique IP address cost in bulk? (IPv6 implies "almost nothing"...) - Even on the level of a single user on DSL, they can often get a new IP just by rebooting their PPPoE connection (this can be automated). IP address + country / ASN / subnet limits - Even more complex - Further centralisation, collateral damage, possibly even a need for manual control. Payment based identity creation - Could be implemented in a somewhat decentralised, transparent manner if wanted e.g. via bitcoin sacrifice (though doing it in a fully centralised way has advantages too e.g. we keep the money!) - Will likely cost us new users. - We don't want to lose existing nodes; attacker may slip in during the transition period, - Unpopular. Gmail accounts etc - Tor uses this for bridges. - Costs more than a CAPTCHA, since they require a unique phone number. - Cheap for any serious attacker to work around this. E.g. buy SIMMs in bulk, register phone numbers, sell the SIMMs. - Used for anti-spam, so presumably there is a market in gmail accounts. - User acceptability nearly as bad as payment. Hardware crypto token - Have to trust the company that produces the tokens. - User acceptability may be better or worse than simple payment; unclear. Likely to cost more than $5, and high latency. - Really a dirty trick to avoid payment based systems. We wouldn't actually use a token much. 3. Use tunnels. The problem with this is that it doesn't give as big a gain as you hope for, because an attacker may be able to dominate tunnel construction via having lots of connections, exploiting the tunnel setup stage. (TODO Quantify: Just how bad is the situation for DHT tunnel setup? IIRC the best algorithms are c/n when we hope for c^2/n^2 on a perfect centralised-trust system, where c = attacker nodes, n = nodes). There are various ways we can do "lightweight" tunnels, and then there are onion-like tunnel setup algorithms. Random routing at high HTL may help a bit too. All of these have a runtime performance cost. It may be worth implementing some of them anyway; for some use cases they may help enough to be worthwhile, raising the number of nodes needed. > > Come to think of it multiple competing adversaries all trying a Sybil > attack might very well interfere with each other. > Depends on what sort of Sybil attack you mean. The simplest Sybil attack on the current network is to connect to everyone and log every request. That only requires a hundred or so nodes, with only minor modifications.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
