-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks yet again for the answers, Caleb! Responses inline.
On 02/08/13 19:03, Caleb James DeLisle wrote: >> That's a big if. Do you currently have a way to detect Sybil >> edges? > > > Sure, I'd just run `cjdcmd traceroute` and look for the nodes > whose names I don't recognize. Sure it doesn't scale but since > attacks are localized, it doesn't have to. I waste 10 minutes and > the attacker wastes their entry point into the network. Getting let > in isn't automatic so getting thrown out doesn't need to be > either. Are you saying that your defense against the Sybil attack is to manually blacklist anyone you don't recognise? And every other user is supposed to do the same? What happens if someone you recognise is automatically generating names you don't recognise? Whack-a-mole... > If you really wanted to automate the process, you could use > heuristics. What heuristics do you have in mind? People have put years of research effort into designing automatic Sybil defenses. The solutions they've come up with (SybilGuard, SybilLimit, Gatekeeper, SybilInfer) are complex and heavyweight, and they depend on assumptions about the structure of the social network - in other words they're not off-the-shelf solutions that you could just drop into cjdns later if the need arises. >> It seems like you're assuming that by minimising the physical >> distance covered by each hop, you can reach the destination >> without ever travelling physically far from the source. But in >> the general case that can't be true, because the destination may >> not be physically close to the source. > > > No, by minimizing the physical distance covered by each hop, you > can reach *someone* who knows the full path to the destination > without traveling physically far from the source. This assumption doesn't scale. As the network grows, the probability that any given node has a full path to the destination falls. If you're already near the destination then sure, you can expect to find a node with a full path to the destination. But in a large network, you don't necessarily start near the destination, and you can't necessarily get near the destination without passing near the attacker. On the other hand, in a small network, you're already near the destination, but you're also already near the attacker. I understand your argument that routing table entries pointing to the attacker will tend to be localised around the attacker. But the same applies to routing table entries pointing to the destination. > The table is populated with physically close and numerically close > nodes, if the destination is physically close you'll probably know > the full path already. If not then the physically closest node who > is numerically closer to the target than you has a better chance > because they're still physically close to you (and thus the target) > and they're numerically closer to the target. Sorry, I don't understand what you mean by "physically close to you (and thus the target)". One doesn't imply the other. >> The difference is significant: if I walk without ever stepping >> far from my previous step, I can still end up far from where I >> started. > > > I think you're confusing "reaching the destination" with "reaching > someone who knows the way". There's only one destination but a > significant portion of nodes know how to get there. As the network grows, the proportion of nodes who know how to get to the destination falls. >> Could you explain how favouring physical diversity of nodes would >> mitigate eclipse attacks and Sybil attacks? > > > Since sybil nodes are clustered in physical space, this would > limit the physical scope of the tablespace exhaustion attack > detailed above. Bear in mind that the attacker can create arbitrarily large Sybil regions of "physical" space. (We should probably avoid calling it physical space - maybe social space would be a better name, because it's defined by social relationships, not by geographical location.) If the attacker creates a Sybil region of social space that's larger than the non-Sybil region, and you try to ensure that your routing table contains a diverse sampling of the whole social space, then your routing table will tend to contain more Sybils than non-Sybils. So it seems to me that favouring physical (social) diversity might be a worse strategy than favouring physical (social) locality, in terms of Sybil resistance. > Also multiple simultaneous sybil attacks could be carried out > using compromised but otherwise valid cjdns nodes. > > I'd like to implement a payment system to limit the first attack, > the second is an open question... How do you approach an attack > where a large number of honest people suddenly become colluding > adversaries? I wouldn't worry about it - right now the network is vulnerable to Sybil and black hole attacks that don't require compromising innocent nodes. Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR/BsPAAoJEBEET9GfxSfMU6gIAJFeL6cCekwqLiWyFCAHWOfP jmeUUjaglG9SMWaea/BJAanMip+AH48b1ptzPpw8JVccMc3QqTBaYdgcg09nxLIw pAB7xgRAbG8lR6U629fMrbvh2ICUpEkkKd9ztVgfPmivsqlbMEEPRA6LjpXHxBbK PZgeYDXBscOypiv2I8XiUqDMVkO3WrrYm7Ge2Dy9rtemG3aY5MN5Wbe4RcxiawpA 7M7Ycmn1uc1+BR486XAudFRoPzSBxLVcDAd5FWclxs2OEwpGqImNj4i5VX1aB17J TfWw2R1ljiDW9c2yKb/NYV6KO8bSFkl8klviA8h31C2APcy2gWBXFV9COIXW/eM= =ckli -----END PGP SIGNATURE----- -- Liberationtech list is public and archives are searchable on Google. Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech
