Am Samstag, 5. Januar 2013, 17:24:03 schrieb Matthew Toseland: > These are all fairly close together so I'll answer them together.
That’s fitting, yes… I just wrote them after each other. > 1. I'm not talking about darknet here AT ALL. I'm only interested in > opennet: The case where we have no Friends, we just want Freenet to work > out of the box. Ah, OK. I’m also interested in the case where we have exactly *one* darknet friend: The one who introduced us into freenet. If we now introduce someone else, FOAF does not help, because we also only know one person. But we can spread opennet noderefs. > Ideally we would like it to provide a reasonable level of > security in this case. Maybe we can make darknet so easy, and freenet so > popular, that opennet is unnecessary; certainly we should try that first > before spending a lot of effort securing opennet. But that's not what I'm > interested in here. > > 2. Opennet is ALREADY a supernode-based semi-centralised network. The > supernodes are pretty dumb and are only involved in bootstrapping. But in > order to get online for an opennet newbie node, or for an established > opennet node after significant downtime, *you need to talk to the > seednodes*. As far as I understand it, the supernodes do not do much more than GWebCaches in Gnutella: Spreading IPs. So instead of requiring full freenet nodes as supernodes, we could use lightweight PHP scripts - which could be hosted by many different people, but would get static IPs or DNS names by being hosted on a regular hoster. So even though the current implementation of Opennet is centralized, the concept behind it is not. It’s just based around having some really long lived points of contact. > No. 1000 students don't suddenly join Freenet: They would likely do so over > a period of time. And if they did join quickly, in some sort of > orchestrated campaign, they'd probably use darknet. They might join after hearing a talk about Freenet. (I might be dreaming here, though :) ) If the CCC would ask people at the 30c3 next year to all run freenet, that could be a significant boost, too. > On the other hand, the cheapest, least visible model for an attacker is to > create a large number of nodes very quickly, probably using a single > ISP/datacentre/Autonomous System Number, hunt down the target, and then > take the nodes (and the target!) offline. Our minimal objective would be, > in the ideal world, to detect this, and thus force them to run a number of > nodes over a longer period, preferably across multiple AS's, thus > increasing costs considerably. Sounds reasonable, yes. > > Can’t this be mitigated decentrally if nodes only accept a limited number > > of new connections from a given location per hour > > No. What is "the given location" ? The given location would for example be a range from 0.11 to 0.12, If that gets significantly more new connections than before, the node would only accept some of them. Maybe 50% more than the hour before. This could also slow down specialization of the network, though… > > - and if opennet nodes which > > don’t manage to get accepted just change their location? > > No. Changing location is a really big deal, because it effectively > invalidates our datastore. Ouch, yes. Please ignore I ever implied changing locations… So throttling must not stop regular nodes, because there is no fallback. (reminds me of my old idea of having two locations, than any attack would very likely only affect one of your locations but not the other…) > Controlling the keyspace, or topology, allows lots of attacks against both > content and inserters, and even against proposed architectures (e.g. > tunnels would likely involve choosing a random node; an attacker that > controls the topology or keyspace can ensure that there's a good chance his > nodes are selected). Is that what pitch black does? How’s the status of our fix on that? Best wishes, Arne -- Ich hab' nichts zu verbergen – hab ich gedacht: - http://draketo.de/licht/lieder/ich-hab-nichts-zu-verbergen
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
