On Thu, Apr 06, 2006 at 12:18:01AM -0700, Ryan Fugger wrote: > On 4/5/06, Matthew Toseland <toad at amphibian.dyndns.org> wrote: > > > > That, unfortunately, is a very interesting question, which we have not > > fully addressed yet. Several options have been proposed. One is to > > expose the topology of the network, or at least a local part of it. This > > is not as radical as it sounds as our current implementation of > > switching does this anyway, admittedly as a side-effect. Further, > > something like this will be necessary for (reasonably well performing) > > premix routing, which is necessary to have good resistance to attacks > > by supposedly trusted peers. Once we have the topology, we can analyse > > it to see what parts of it are likely to be bogus, and we can enforce > > swaps. This is not implemented yet on Freenet :). > > Do you mean that the neighbour who delivers the swap message enforces > swaps by also informing all the node's other neighbours? > > For my application, exposing local topology is a little testy. But I > see how it would be impossible to enforce location swaps without doing > so, since someone who didn't like a potential swap location could just > invent a set of neighbour distances that make the swap very unlikely. > In that case, swapping might as well be completely on the honour > system, which might be OK, but isn't preferable.
Exposing topology is bad, I agree, but it seems to be the only way to make swapping entirely secure... and it's also required for premix routing. We don't necessarily have to expose *all* the topology.. > > Have you thought much about using TPM chips to authenticate "honest" > software instances to each other? Sure, they're made for evil DRM > applications, but I think there could be ways to use them for the > purposes of good :) LOL. Definitely not possible for freenet, and not just for political reasons; we need it to run "anywhere" or as near to anywhere as possible. > > > > * How do you pre-vent a node from using multiple routing locations, > > > each with different neighbours, to improve its findability? > > > > See above. One thing you can exploit is that it is generally difficult > > to convince somebody to trust you under two completely different > > identities; this *may* help to do some network analysis to establish the > > credibility of a node; I've also thought about some sort of scoring > > system. > > Yes, but you might decide to masquerade as a different node entirely > to some of your neighbours. I guess that wouldn't break routing if > you were doing swaps honestly for each "node" you were operating, > though. > > > > > > > * How do you prevent nodes from spoofing other nodes' locations as an > > > attack? > > > > In a swap request? Only way you can do this is by some sort of > > enforcement, and with only credible nodes permitted to participate in > > swapping. > > Not in a swap request, but in general. For example, suppose the > thought police knew the freedom fighters were operating a node at > location A. What stops them from attaching thousands of new nodes up > to the network, all claiming that they are location A in order to suck > legitimate messages for A to their nodes and intercept them? Well, if the swap algorithm is enforced, it would probably need an initial bootstrap location choosing mechanism; in any case, once a node with a fake location gets on the network, the fake location can be swapped... it won't be if his neighbours are also really close though. The best he can do is to intercept requests coming to location A; he won't be able to get close to a pre-existing node just by having a close location. Can he intercept requests close to A? Maybe, if the swap algorithm likes him and adjusts the rest of the network so that requests near his location get routed to him... > > How tolerant is your messaging scheme to multiple nodes with the same > routing location? I guess any decentralized addressing scheme is > vulnerable to this type of attack, and most probably more so than the > type of trust network we're dealing with here. As an attack, it wouldn't be "the same", it'd be "really close"... > > > The main advantage of using MH is that it can scale almost indefinitely. > > If you don't need this you're better off with something more well known, > > more well tested and more well studied. > > For me, one of the main advantages is the anonymous nature of the > transient routing locations. Well it's somewhat anonymous, but really it needs a premix layer on top. There are statistical attacks possible with requests, probably with anything else that can be easily correlated; the basic problems are: - If you make a bundle of requests for a splitfile, your neighbour nodes will be able to see (if they are clever and know the splitfile) that these requests are connected, and that you're requesting too big a part of it to be (likely) forwarding requests for other nodes. - That the request is a long way away from the target location: the node you got it from is forwarding a request which is very close to the originator node, or it would have gotten further by now. Both of these can be used for fairly powerful attacks, assuming you are directly connected to the target; we will in 0.8 introduce premix routing. > > > > > We have a plugin API for things which use the basic Freenet > > functionality already (fetching stuff, inserting stuff). I have been > > thinking about an API for apps which deal directly with peers, for > > things like local filesharing or instant messaging. It might be possible > > to run your app on this, or we might want to provide a low level plugin > > interface for stuff that uses routing. > > A local messaging API that provided location management would probably > be enough for me. > > Ryan -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20060406/baf14a6b/attachment.pgp>
