-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Caleb,
On 01/08/13 17:20, Caleb James DeLisle wrote: >> At this point, Alice knows that Carol is "real" in the sense that >> someone owns Carol's private key and uses it to respond to pings. >> But Alice has no way to determine whether Bob and Carol are >> actually the same person. In other words, Alice can't tell >> whether Carol is a Sybil. > > Correct. So if Alice can't tell whether Carol's a Sybil, presumably Alice can't avoid sharing information about Sybils when sharing routing table entries. So people who trust Alice to be honest and diligent can't trust her to give them non-Sybil routing table entries. > To rephrase, given the architecture, I don't know of any attack > which would be effective enough to warrant specific defenses. Of > course changing IP addresses to send SMTP spam or evade IRC bans > could be considered a sybil attack. I was thinking of more subtle attacks, such as dropping (some or all) data packets while responding correctly to pings. Sybil identities would serve two purposes in such an attack: filling as many routing table slots as possible with attacker-controlled identities, and evading fault detection by replacing any identities detected as faulty. >> Yes, I agree that detecting and dropping faulty nodes is >> pointless as long as there's no limit on the creation of >> identities. > > > This is not true. If I want to ban you, I won't express the ban as > your key where you can just make another, I'll express it as your > peer's key and the interface index which is used to get from him to > you. > > This way you can ban sybil edges if you can identify them. That's a big if. Do you currently have a way to detect Sybil edges? Returning to the example above: Alice's friend Bob tells her about his friend Carol. Alice can't tell whether Carol's a Sybil. So if Alice detects (somehow) that Carol is misbehaving, should she (a) ban Carol, (b) ban the edge from Bob to Carol, (c) ban Bob, or (d) ban the edge from Alice to Bob? If it turns out that Carol is a Sybil created by Bob then (a) and (b) are a waste of time - Bob can just create a new Sybil. If it turns out that Carol wasn't created by Bob then (c) and (d) are collateral damage: the attacker has caused a genuine node or edge to be banned. Alice doesn't know whether Carol was created by Bob, so whatever action she takes is useless at best and harmful at worst. > The non-forwarding node attack does concern me since it's hard to > identify but again it is a physically local attack. The cjdns > implementation conservatively forwards to the physically nearest > node which makes any forward progress in address space and since > the routing table is heavily duplicated, I'm likely to get to the > destination long before I reach a non-forwarding node. Sorry, I don't understand how forwarding to the physically nearest node at each hop will help to avoid faulty nodes. 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. Furthermore, the source and destination are at random points in the address space, and every hop must make progress in the address space. So even if the source and destination are physically close together, there's no guarantee that there's a path between them where every hop makes progress in the address space while remaining physically close to the source. What's more, the routing algorithm doesn't even try to find such a path - it tries to find a path where every hop makes progress in the address space while remaining physically close to the *previous hop*. 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. So I'm not convinced that the routing algorithm avoids passing through nodes that are physically distant from the source. > After looking over the first couple pages of Eclipse Attacks on > Overlay Networks: Threats and Defenses I can see a tablespace > exhaustion attack based on answering every DHT query with a fake > node which is numerically very close to the target. Unless they're > physically close to the victim they won't normally be routed to but > they will take up space in a size limited table which would reduce > the duplication of the routing table causing packets to be routed > further and making localized sybil attacks have a wider reach. > > This attack, as with many others, depends on the implementation of > cjdns. Because there are hard rules preventing loops, we could > adopt a new table population algorithm which favors physical > diversity of nodes, mitigating this and other sybil type attacks > without breaking the cjdns protocol. Could you explain how favouring physical diversity of nodes would mitigate eclipse attacks and Sybil attacks? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR+veCAAoJEBEET9GfxSfMsX4IALeMrsfKlxLxMvPpk0LdqYXd lrjjNJX716IsvhG57ifOeHj6zgo4tfzT+45TvyuTAJlVMcBxm/xp9/UaIDNrWpld H5Z7fHeKUz2iGLwMdI/uMn3Zn0z3X8g5sw2W4PecYY8hn4X8N7dKwmo0DauadZZJ 7B5qxUB4+Gm6/PXGo3KAEqZ6zIMjiWl5LTGS8CD5Oc9nM2upezydVsobnCn32eAu 1PMoavTZhZ6ZTZITc2gUMbjn96DOuBAm1OZMroF/bzFcKRrUbvbAlTVxT78bLIJh v39RvwnYiJiiNxoK/2IQy7KlrPkSR1OmBFze5d3pZUuES3X5K89qB/RtR38HTIY= =QxC9 -----END PGP SIGNATURE----- -- Liberationtech list is public and archives are available via 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
