Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/08/13 19:55, Caleb James DeLisle wrote: This is good from a capabilities standpoint but it doesn't cover motive which is hugely important to threat modeling. If someone has significant resources and their motive is to cause mayhem, securing infrastructure against them is not really possible which is why traditional antiterrorism efforts seem incoherent. Ah! I think you've uncovered an unstated assumption of mine that might explain a lot of our disagreements. This conversation started with a question about whether cjdns was suitable for resisting government censorship. So the adversary I've been imagining is a government: she has lots of resources, and will be satisfied if she can make cjdns unusable for some or all users. I should've made that assumption explicit a long time ago! The attacks I've been describing - running a bunch of nodes, infiltrating the social network, attacking the protocol from within, creating Sybil identities to protect the infiltrators from detection - are clearly very resource-intensive, and I wouldn't expect anyone less powerful and organised than a government to carry them out. Having said that, the adversary I've described isn't omnipotent - she's a realistic adversary that we might realistically hope to oppose. Another motive for localized DoS is to force users to an unencrypted channel. If every time the police use encrypted radio you jam it, they may be tricked into using unencrypted channels. The main defense against this is not to have an insecure backup. I agree with that defense, but unfortunately there's often an insecure backup that's outside your control: users can switch to an entirely different method of communicating. If the adversary can disrupt cjdns without disrupting the legacy internet, she can encourage users to switch back to the legacy internet, where they can be censored and surveilled. Also note that localized network outages can be caused by wire cutters and/or wifi jammers so a protocol attack may never be the most effective approach. True, but protocol attacks are more selective than physical attacks and may be harder to attribute. (Of course, the adversary may use both approaches at once.) How would you find a set of known evil nodes? cat-and-mouse games which is why I don't like this approach. You could send forwarded packets to nodes to whom you know a direct path and then send them a direct packet asking if they got the forwarded packet. You have to try it a few times to be sure the endpoint is not fooling you and there are still more ways to detect and work around it. It's not something I'm interested in ever implementing so it's not really worth further discussion. I agree that these cat-and-mouse games are pointless, which is why I'm skeptical about vague answers like use heuristics. The point I was trying to make in my first email is that the Sybil attack is actually an entire class of attacks. If you solve one specific instance, the attacker can just use a different instance. The same applies to Byzantine routing faults. Faced with a class of attacks like that, it seems to me that you have three options: 1. Decide that you can't defend against this class of attacks. This is a perfectly legitimate option - every system has limits beyond which it doesn't claim to work. Arguably, Tor succeeded where anonymous remailers failed because Tor tried to defend against a less powerful, but still realistic, adversary. 2. Demonstrate that you have a general solution to the entire class of attacks. This is possible, but the resulting solutions may not be practical to use - see Perlman's work on Byzantine robust routing and the SybilGuard family of protocols for two examples. 3. Demonstrate that the entire class of attacks is irrelevant to your system. For example, a system with no routing doesn't have to worry about Byzantine routing faults. It's possible that you've already chosen option 1 and I've misunderstood the kind of adversary you aim to protect against, in which case I apologise for wasting your time with this long thread (although it's taught me a lot about cjdns - thanks for that). - From our discussion so far, I don't think you've chosen option 2 or 3, because I think we've established the following points: * Sybil attacks can have (at least) a localised effect * There's currently no detection or prevention of packet-dropping attacks, as long as the attacker doesn't drop pings * Even if a randomly chosen source and a randomly chosen destination are each surrounded by trustworthy nodes, there isn't necessarily a physical path between them that only passes through trustworthy nodes It seems to me that those three points add up to a reasonable doubt about whether cjdns could be disrupted by a combination of Sybil attacks and packet-dropping attacks. I don't think it would be fruitful to simulate a specific attack and design a specific solution,
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Caleb, On 03/08/13 01:33, Caleb James DeLisle wrote: We could spend a long time discussing locally effective attacks on social networks and not be any closer to agreement. Instead I think it's worth asking who your attacker is... I find that when people don't stop to ask who the attacker is, what he wants and what resources he can apply on the attack, they end up with a default assumption that the attacker is everywhere and has infinite resources. If you can give me a clear picture of the person who would use this attack, what they want from the attack and what resources they can bring to bear on the problem, I might be able to speak more to the issue. Excellent point! The adversary I have in mind looks something like this: * Can create adversarial nodes * Can persuade a limited proportion of users to make direct connections to adversarial nodes * Can co-ordinate the behaviour of all adversarial nodes * Can create low-latency, high-bandwidth connections between adversarial nodes * Can't monitor or tamper with direct connections between non-adversarial nodes * Can't break standard crypto primitives * Aims to degrade the performance of cjdns for some or all users What heuristics do you have in mind? Given a set of known evil nodes, find the longest common route prefix(es) which contain all of the evil nodes. The last node along each common prefix is probably an edge. How would you find a set of known evil nodes? 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. They operate under different constraints. Could you elaborate on the differences? The systems I mentioned are designed for use in P2P networks where the edges are based on real-world social relationships and there's no central authority. Isn't that similar to the cjdns setting? Everybody knows paths to those who are the numerically closest to themselves no matter the physical distance. Since addresses are spread randomly throughout the network, it means that anyone given node is directly reachable from a few nodes in each physical locality of the network. Let's consider what happens as the network grows. On average, each node is pointed to by t routing table entries, where t is the size of a node's routing table. As the network grows, the t entries pointing to a given node will be spread more thinly across the network, unless we increase t in direct proportion to the number of nodes. Increasing t like that won't scale indefinitely, but for the sake of argument let's assume it will scale well enough for whatever size cjdns grows to. So wherever we start from, there's some nearby node that knows a switching path to the destination. However, the length of that switching path will increase (on average) as the network grows. Even if we had a magic oracle that told us the shortest path to any destination, that path would still be longer on average in a large network than a small network. Therefore if some proportion of the nodes are adversarial, the probability of hitting an adversarial node on the way from a randomly chosen source to a randomly chosen destination will increase as the network grows. 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. The number of nodes and the way they're organized doesn't help. They're all behind a common label prefix (the path to the sybil edge) and that label prefix would cause them to be seen as a cluster. Unfortunately it's not that simple. You're assuming that from the point of view of a given node, all the Sybils are behind a single edge (an attack edge, in SybilGuard terminology). But a given Sybil may be reachable via multiple attack edges. That's why SybilGuard and its descendents are so complex: before sampling the network to look for clusters, they have to ensure that there's only a single way for samples to reach each node. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR/+ApAAoJEBEET9GfxSfMa8kH/iK0/TIHXiHSAZoDReJJmljD kPVxkMTa/ejYdRWdDZ2VV6wiTGS7OuMJ4gYk6e8k6mqc3PmcdS8gDRC0ZQBOve44 Oy6b4XtozOJBWB+5K1M4DRMQefoAxttrQD6v6C8ov1eyPqIIPcnPAYRUYufDdphK VmGYFmbGNTvb2If7YfN1xVgbTX1Kyq+5oKAyFtJflMiBRZtFHgSRvVNoTIIfD2Sj K2h0LriJTSvd4SW0/gxtSs20+ZxkjsitgAlaWNWwyvyJDWygYeIzU0KSDFegwnNd 3UtCOF1/WF784RoXwiHwVxAPp4AZ+yfRQ5hwuTRhiUYxCjfEPYRV9E1ckFskyIE= =dVi8 -END PGP SIGNATURE- -- Liberationtech list is
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On 08/05/2013 01:26 PM, Michael Rogers wrote: Hi Caleb, On 03/08/13 01:33, Caleb James DeLisle wrote: We could spend a long time discussing locally effective attacks on social networks and not be any closer to agreement. Instead I think it's worth asking who your attacker is... I find that when people don't stop to ask who the attacker is, what he wants and what resources he can apply on the attack, they end up with a default assumption that the attacker is everywhere and has infinite resources. If you can give me a clear picture of the person who would use this attack, what they want from the attack and what resources they can bring to bear on the problem, I might be able to speak more to the issue. Excellent point! The adversary I have in mind looks something like this: * Can create adversarial nodes * Can persuade a limited proportion of users to make direct connections to adversarial nodes Infecting existing nodes is cheaper than knocking on doors asking people to connect to your evil nodes because your reputation doesn't suffer when the trick is discovered. * Can co-ordinate the behaviour of all adversarial nodes * Can create low-latency, high-bandwidth connections between adversarial nodes It doesn't cover whether adversarial nodes are geographically dispersed or not. If they are then the the attack is significantly more expensive. * Can't monitor or tamper with direct connections between non-adversarial nodes * Can't break standard crypto primitives * Aims to degrade the performance of cjdns for some or all users This is good from a capabilities standpoint but it doesn't cover motive which is hugely important to threat modeling. If someone has significant resources and their motive is to cause mayhem, securing infrastructure against them is not really possible which is why traditional antiterrorism efforts seem incoherent. Causing localized network disruption is trivial in any ethernet, you simply answer ARP or DHCP packets. This is done by some malware but the motive is to carry out a MiTM attack and trick the victim into installing the malware binary which is disguised as an update. With cjdns you would not have the ability to MiTM so the same style attack would just cause a localized network outage. Another motive for localized DoS is to force users to an unencrypted channel. If every time the police use encrypted radio you jam it, they may be tricked into using unencrypted channels. The main defense against this is not to have an insecure backup. Also note that localized network outages can be caused by wire cutters and/or wifi jammers so a protocol attack may never be the most effective approach. What heuristics do you have in mind? Given a set of known evil nodes, find the longest common route prefix(es) which contain all of the evil nodes. The last node along each common prefix is probably an edge. How would you find a set of known evil nodes? cat-and-mouse games which is why I don't like this approach. You could send forwarded packets to nodes to whom you know a direct path and then send them a direct packet asking if they got the forwarded packet. You have to try it a few times to be sure the endpoint is not fooling you and there are still more ways to detect and work around it. It's not something I'm interested in ever implementing so it's not really worth further discussion. 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. They operate under different constraints. Could you elaborate on the differences? The systems I mentioned are designed for use in P2P networks where the edges are based on real-world social relationships and there's no central authority. Isn't that similar to the cjdns setting? I suppose it is because the same information can be derived, albeit with some complexity. In cjdns the path through the social network which is represented by any given node is expressed in the label so you get it for free. Everybody knows paths to those who are the numerically closest to themselves no matter the physical distance. Since addresses are spread randomly throughout the network, it means that anyone given node is directly reachable from a few nodes in each physical locality of the network. Let's consider what happens as the network grows. On average, each node is pointed to by t routing table entries, where t is the size of a node's routing table. As the network grows, the t entries pointing to a given node will be spread more thinly across the network, unless we increase t in
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/01/2013 08:04 PM, Michael Rogers wrote: 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. Indeed, if sybil nodes are physically close to Alice then they will get favorable locations in her table and thus be shared and forwarded to. As Alice shares with Bob and Bob shares with Charlie, the path becomes longer and less favorable and the chance of that sybil node being shared again decreases thus localizing the attack in physical space. I had said that the majority of the nodes being honest keeps the table clean, I misspoke. Most nodes being non-attackers improves the table but this is obvious. If Alice hands me a far off sybil node with a long route, I will rarely (if ever) route to it anyway so assuming Alice is any less than an attacker, her conformance is not important. 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? 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. 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. If you really wanted to automate the process, you could use heuristics. 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. 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. 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. The table is
Re: [liberationtech] CJDNS hype
-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)
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/02/2013 04:48 PM, Michael Rogers wrote: 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... We could spend a long time discussing locally effective attacks on social networks and not be any closer to agreement. Instead I think it's worth asking who your attacker is... I find that when people don't stop to ask who the attacker is, what he wants and what resources he can apply on the attack, they end up with a default assumption that the attacker is everywhere and has infinite resources. If you can give me a clear picture of the person who would use this attack, what they want from the attack and what resources they can bring to bear on the problem, I might be able to speak more to the issue. If you really wanted to automate the process, you could use heuristics. What heuristics do you have in mind? Given a set of known evil nodes, find the longest common route prefix(es) which contain all of the evil nodes. The last node along each common prefix is probably an edge. 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. They operate under different constraints. 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. Everybody knows paths to those who are the numerically closest to themselves no matter the physical distance. Since addresses are spread randomly throughout the network, it means that anyone given node is directly reachable from a few nodes in each physical locality of the network. 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. There's a subtle distinction, routes propagate throughout the network but unless they are physically close, they are not used unless they are an exact match. In other words: I route to the physically closest node who makes forward progress in address space *unless* I have a node whose address matches the target, in which case I route to him. 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. I was responding to this: even if the source and destination are physically close together, there's no guarantee that there's a path between them... Where the premise is that there's a node which is physically close to you but you're unaware of them. The difference is significant: if I walk without ever stepping far from my previous step, I can still
Re: [liberationtech] CJDNS hype
-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
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Michael, Sorry for the wait on my part as well, I was very busy last week. On 07/24/2013 05:27 AM, Michael Rogers wrote: Hi Caleb, Thanks for the detailed answers - I'm sorry it's taken me so long to reply. - From your answers and the whitepaper I think I'm starting to understand how the switching and routing layers fit together. Would I be right in thinking that each node populates its DHT routing table with nodes that are one or more hops away at the switching layer, and that each hop at the switching layer is a link between two people who know each other? So two nodes that are neighbours at the DHT layer are't necessarily neighbours at the switching/social layer? Exactly. There is no real concept of neighbors at the DHT layer but there is address space distance so some nodes are close. And if there's more than one candidate for a slot in the DHT routing table, am I right in thinking that some weighted combination of DHT ping time and label length is used to pick the best candidate, where label length is a combination of path length (at the switching layer) and the degree of the nodes along the path (with short paths and low-degree nodes resulting in shorter labels)? Yup. More generally, could you explain how CJDNS detects and routes around faults? The simple version is that it pings at random nodes in it's table. When a node is unresponsive, it and anyone who is behind it is dropped from the table. A few questions about pings: Is it possible for a node that's being pinged to distinguish a ping from a data packet? (What would happen if a node responded correctly to pings but dropped data packets?) Yes, the destination of the ping does know that it's a ping since it needs to respond to it. If it dropped non-pings it would be unreachable and if it dropped layer3 forward me messages then it would break the network. Can a node on the switching path between the pinger and the pingee distinguish a ping from a data packet? Only by guessing based on size and timing. Can a node on the switching path between the pinger and the pingee respond to a ping on the pingee's behalf? Never ever. That's critical to the model that when you are told about a node that you don't trust that it's real until you're sure that you've talked to it. Could you explain what a route prefix is and how you can be sure that a set of Sybil identities will share a route prefix? How is the route prefix used in detecting and routing around faults? This requires understanding the base method by which cjdns works. When I start up my router, I connect to my specified peers which I have manually configured, these are people whom I know well enough to be assured that they are honest peers. Then my node's switch core assigns each one an interface index. My node then compresses the interface indexes of it's neighbors into a label and inserts the entries with key and label into it's routing table. My node randomly asks nodes in it's routing table for pieces of their table, the question could be simplified as who do you know, how do you reach them, the response from them is entries taken directly from their routing table. When Alice tells me that she knows Bob and his label is 12345, I take Alice's label which might be abcd and splice them together to have a label which routes from me to Alice to Bob, then after Bob has been pinged along this path, I begin to trust it. This is all an oversimplification, for the actual way it works please consult the whitepaper. Thanks, that's a really helpful explanation. So it seems to me that you're using the same observation as SybilGuard and similar systems: although the number of Sybils is unlimited, the number of social edges between Sybils and non-Sybils is limited, so those edges can be used to limit the impact of Sybils. It's a cool observation, but the devil's in the details - how do you actually apply that observation in practice? Is there some algorithm in cjdns that detects anomalous routing table entries by examining the prefixes of their switching labels? Other than short paths (labels) being preferred, there are only a few tricks aimed specifically at accidental problems. If I discover route a-b-c-d-w-x-y-z-d then I discover a-b-c-d I will replace the first with the second since I can prove that the first is an indirect representation of the second. There are no specific defenses against sybil attacks but I don't think any are needed given the fact that it's inherently different from a traditional overlay network. Could you explain why a set of Sybil identities will produce an absurdly long path, and how you can be sure that the routing table has already been populated with fast non-Sybil nodes? Re the absurd length of paths, since more nodes mean more interface indexes, it stands to reason that the
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 15/07/13 01:49, Mitar wrote: BTW, how do you propose to make Sybil nodes impossible? I don't. I am just making an argument, that maybe there is some way we (or I) don't yet know which would allow us to don't have to trust other nodes with anything else that they forward the packet. And if they don't, we can maybe detect that and remove them from the routing path. So at the end maybe it is not even important if Sybil nodes are possible or impossible. You just care if they forward the packet. If they do, this is it. If they don't (from whatever reason, being malicious or just malperforming), you route along that, no? But to be able to route around, you have to be able to have multiple paths. Hi Mitar, If there's no protection against Sybil attacks then in general it's impossible to route around faulty nodes or links. The problem is that in order to detect faults, we have to associate some kind of reliability measurement with some kind of node or link identifier (for example, x percent of packets sent via link y were delivered). If there's no Sybil protection then whenever we detect a node or link as being faulty, the adversary can simply create a new identifier for that node or link. The adversary can create imaginary networks of arbitrary size and structure, composed entirely of Sybil identities, to absorb our measurement resources. It's like playing whack-a-mole with an infinite number of moles. ;-) If we consider the most limited form of Sybil protection, where we know that our immediate neighbours in the network aren't Sybils (for example, maybe they're people we know in real life) but we don't know anything about the rest of the network, then we can do a very limited form of fault detection: we can measure the reliability of each neighbour, without speculating about what the network beyond that neighbour looks like, and route around unreliable neighbours. But that's not as easy as it sounds: if the adversary can distinguish between different types of packet then she can treat them differently. For example, if the network uses separate measurement packets and data packets, the adversary can deliver measurement packets but drop data packets. If the packets carry source or destination addresses, the adversary can drop packets with certain sources or destinations while keeping her overall reliability high. The adversary may be able to manipulate the reliability measurements without dropping packets, for example by spoofing addresses or forging measurement packets. This problem is known as Byzantine robust routing. It was first framed by Radia Perlman in 1988, and so far nobody's come up with a solution that doesn't require some kind of limit on the creation of identities. Many have tried and failed. I was one of them. :-) I don't know enough about CJDNS to know whether it's solved this problem, but I'll be pleasantly surprised if it has. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBAgAGBQJR5AyxAAoJEBEET9GfxSfM2OwIALyIROECcLGCiJlyM8DX6IKQ aQdC4JFfcgsh1poTq1MaHjF1nCUA14OBF73bpxp0iRw8b0fcJ4AwqAlzdDbxL1k0 cfxdaytN6dZPSgQng6jot4o4GzCYdVNdWcAxsycNgohjX0MDa64pe6gJmYmZlmBw S24FB8ismcMl3Ohyu1mg339NsBzo6is3zKa9/TVp5l5iB/FVFM8yjTewkAgdBFVD BlOLwEr5h+gHUqTpmmswXbJIcqT9/xe14NogKOgUDUUfpZMe7g0ZWeF7z65FJwLn C2kVc/HxB85TTmwaGoV/Os79lQALLVNmdafgqHhcRRNTTCRUKcqlgDsZt6/SsEE= =ud7U -END PGP SIGNATURE- -- 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
Re: [liberationtech] CJDNS hype
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/15/2013 04:52 PM, Michael Rogers wrote: On 15/07/13 01:49, Mitar wrote: BTW, how do you propose to make Sybil nodes impossible? I don't. I am just making an argument, that maybe there is some way we (or I) don't yet know which would allow us to don't have to trust other nodes with anything else that they forward the packet. And if they don't, we can maybe detect that and remove them from the routing path. So at the end maybe it is not even important if Sybil nodes are possible or impossible. You just care if they forward the packet. If they do, this is it. If they don't (from whatever reason, being malicious or just malperforming), you route along that, no? But to be able to route around, you have to be able to have multiple paths. Hi Mitar, If there's no protection against Sybil attacks then in general it's impossible to route around faulty nodes or links. The problem is that in order to detect faults, we have to associate some kind of reliability measurement with some kind of node or link identifier (for example, x percent of packets sent via link y were delivered). If there's no Sybil protection then whenever we detect a node or link as being faulty, the adversary can simply create a new identifier for that node or link. At the switch layer, the path is a binary encoded list of interface indexes of the interfaces through which the packet should pass, think of it like driving directions. Each node along the path modifies the packet, removing the forward index and tagging it with the index of the interface from which it came. This means you can send someone a switch frame with *anything* in the label and when it gets to them, the beginning of the label will contain a nicely formatted route leading back to you. You can spoof a switch frame source but the path will always appear to go through your node. The adversary can create imaginary networks of arbitrary size and structure, composed entirely of Sybil identities, to absorb our measurement resources. It's like playing whack-a-mole with an infinite number of moles. ;-) Which will all have a common route prefix. Lazy cjdns will not route to your absurdly long path if it has short paths to the destinations it wants to reach. It will also not care much about your zillion nodes because it has fast nodes already in it's routing table and they're working just fine. If we consider the most limited form of Sybil protection, where we know that our immediate neighbours in the network aren't Sybils (for example, maybe they're people we know in real life) but we don't know anything about the rest of the network, then we can do a very limited form of fault detection: we can measure the reliability of each neighbour, without speculating about what the network beyond that neighbour looks like, and route around unreliable neighbours. You can feign existence of as many nodes as you want but you can't feign low latency and short labels, in fact the more nodes you generate, the longer your labels will become to accommodate them all, your (comparatively) high latency links with long switch labels look just like a terrible route which cjdns finds and rejects all of the time. But that's not as easy as it sounds: if the adversary can distinguish between different types of packet then she can treat them differently. For example, if the network uses separate measurement packets and data packets, It doesn't (of course you can guess based on size and flow information) the adversary can deliver measurement packets but drop data packets. If the packets carry source or destination addresses, They don't, only route labels which route to the next hop in the recursive routing which is usually but not necessarily the destination. the adversary can drop packets with certain sources or destinations while keeping her overall reliability high. The adversary may be able to manipulate the reliability measurements without dropping packets, for example by spoofing addresses or forging measurement packets. Can't spoof a packet because the IPv6 address is the public key hash. Can't spoof a switch frame source except to extend the length of the path beyond your node. This problem is known as Byzantine robust routing. It was first framed by Radia Perlman in 1988, and so far nobody's come up with a solution that doesn't require some kind of limit on the creation of identities. Many have tried and failed. I was one of them. :-) I don't know enough about CJDNS to know whether it's solved this problem, but I'll be pleasantly surprised if it has. If you want to cause trouble for cjdns, just exploit https://github.com/cjdelisle/cjdns/issues/204 before I get off of my lazy ass and fix it :) Thanks, Caleb Cheers, Michael -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at compa...@stanford.edu or
Re: [liberationtech] CJDNS hype
Hi! On Sun, Jul 14, 2013 at 5:01 AM, Ralph Holz h...@net.in.tum.de wrote: I don't see how no need to make a decision should be possible. If you don't know any contacts in the network, how are you supposed to trust them? Ideally, you shouldn't have to trust anybody. :-) You should be able to turn on your overlay network node, it should connect to the network, and you should be able to communicate with anybody, despite somebody trying to censor you. Sadly, it seems we are not yet there. Or maybe we will never be. First of all, they use recursive routing instead of iterative lookups (that's important to deal with the attacker on the IP level). Then they use a random walk to get around a tactically acting attacker trying to occupy important spots in the network, before they switch to the normal routing. It seems CJDNS is using the recursive routing approach? But isn't so that it is enough that in the whole routing path you get only one adversary node and this node can black hole your packets? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
Re: [liberationtech] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: Hi! I am a bit concerned with the CJDNS hype I am observing around. I do like that decentralized Internet is getting momentum, but I am concerned if CJDNS is really the way to achieve that. From its whitepaper it seems that it is susceptible to a Sybil attack: After this thread started I wrote to the author— as I'd pointed out before I had the same concerns initially but had spoken to him and basically came away with an impression that he was aware of the problem space and wasn't doing the dumbest possible thing as a result— and there was at least a fighting chance that the system addressed the issue, but I didn't care (or, really, have time) to understand more at the time, so I couldn't write an actual explanation. He seems to be having some problems getting onto the list, so he sent me a response to reflect up to it: - CUT HERE - The answer to ID clustering attacks is that cjdns is just really lazy, it routes to the physically nearest node whose ip address is numerically closer to the destination than your own (based on KAD). Since the physical topology is friend-to-friend, the attacker is forced to have a relatively tight cluster of nodes in physical space, they can pollute their own neighborhood but not the whole network. Pollution of one physical neighborhood would likely lead to them being de-peered by their friend who gave them the link. Re the recursive routing, it has two options. You can send direct to the destination at the switch level or you can forward to any node in the network and ask them to forward to the destination. The nodes between you and the one you asked to forward will have no access to the IPv6 dest address and if the one you are forwarding to us unfriendly, you use someone else. We've considered changing this to improve scalability but I can't figure out how to preserve this guarantee. The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Again though the physical reality of the network comes in to play. The nodes which carry the majority of the traffic are heavily peered core nodes and the operators of such are unlikely to intentionally attack the network, this is the same logic which holds BGP together despite it's painful frailty. Hope that helps Thanks, Caleb -- 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
[liberationtech] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: Hi! I am a bit concerned with the CJDNS hype I am observing around. I do like that decentralized Internet is getting momentum, but I am concerned if CJDNS is really the way to achieve that. From its whitepaper it seems that it is susceptible to a Sybil attack: After this thread started I wrote to the author— as I'd pointed out before I had the same concerns initially but had spoken to him and basically came away with an impression that he was aware of the problem space and wasn't doing the dumbest possible thing as a result— and there was at least a fighting chance that the system addressed the issue, but I didn't care (or, really, have time) to understand more at the time, so I couldn't write an actual explanation. He seems to be having some problems getting onto the list, so he sent me a response to reflect up to it: - CUT HERE - The answer to ID clustering attacks is that cjdns is just really lazy, it routes to the physically nearest node whose ip address is numerically closer to the destination than your own (based on KAD). Since the physical topology is friend-to-friend, the attacker is forced to have a relatively tight cluster of nodes in physical space, they can pollute their own neighborhood but not the whole network. Pollution of one physical neighborhood would likely lead to them being de-peered by their friend who gave them the link. Re the recursive routing, it has two options. You can send direct to the destination at the switch level or you can forward to any node in the network and ask them to forward to the destination. The nodes between you and the one you asked to forward will have no access to the IPv6 dest address and if the one you are forwarding to us unfriendly, you use someone else. We've considered changing this to improve scalability but I can't figure out how to preserve this guarantee. The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Again though the physical reality of the network comes in to play. The nodes which carry the majority of the traffic are heavily peered core nodes and the operators of such are unlikely to intentionally attack the network, this is the same logic which holds BGP together despite it's painful frailty. Hope that helps Thanks, Caleb -- 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
Re: [liberationtech] CJDNS hype
Hi guys, Thanks Eugen and Greg for mailing me about this. The answer to ID clustering attacks is that cjdns is just really lazy, it routes to the physically nearest node whose ip address is numerically closer to the destination than your own (based on KAD). Since the physical topology is friend-to-friend, the attacker is forced to have a relatively tight cluster of nodes in physical space, they can pollute their own neighborhood but not the whole network. Pollution of one physical neighborhood would likely lead to them being de-peered by their friend who gave them the link. Re the recursive routing, it has two options. You can send direct to the destination at the switch level or you can forward to any node in the network and ask them to forward to the destination. The nodes between you and the one you asked to forward will have no access to the IPv6 dest address and if the one you are forwarding to us unfriendly, you use someone else. We've considered changing this to improve scalability but I can't figure out how to preserve this guarantee. The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Again though the physical reality of the network comes in to play. The nodes which carry the majority of the traffic are heavily peered core nodes and the operators of such are unlikely to intentionally attack the network, this is the same logic which holds BGP together despite it's painful frailty. Hope that helps Thanks, Caleb On 07/14/2013 04:50 PM, Eugen Leitl wrote: - Forwarded message from Mitar mmi...@gmail.com - Date: Sun, 14 Jul 2013 05:55:37 -0700 From: Mitar mmi...@gmail.com To: liberationtech liberationtech@lists.stanford.edu Subject: Re: [liberationtech] CJDNS hype Reply-To: liberationtech liberationtech@lists.stanford.edu Hi! On Sun, Jul 14, 2013 at 5:01 AM, Ralph Holz h...@net.in.tum.de wrote: I don't see how no need to make a decision should be possible. If you don't know any contacts in the network, how are you supposed to trust them? Ideally, you shouldn't have to trust anybody. :-) You should be able to turn on your overlay network node, it should connect to the network, and you should be able to communicate with anybody, despite somebody trying to censor you. Sadly, it seems we are not yet there. Or maybe we will never be. First of all, they use recursive routing instead of iterative lookups (that's important to deal with the attacker on the IP level). Then they use a random walk to get around a tactically acting attacker trying to occupy important spots in the network, before they switch to the normal routing. It seems CJDNS is using the recursive routing approach? But isn't so that it is enough that in the whole routing path you get only one adversary node and this node can black hole your packets? Mitar -- 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
Re: [liberationtech] CJDNS hype
Hi! On Sun, Jul 14, 2013 at 8:56 AM, Ralph Holz h...@net.in.tum.de wrote: I wasn't talking about the routing - I was referring to just who that other person might be. If you want to avoid censorship, you also need to be sure who you're talking to. And there is no way to achieve that without prior setup of trust. Not necessary. If you (in some abstract overly network) connect to multiple other nodes and Sybil attacks (so fake identities) in the network are impossible, then there is a low probability that all of those nodes would be controlled by the adversary. If you send a request to all of them, and they repeat the same thing ... This example might be impractical, but it is here just to show that it might not be necessary to know your peers. So yes, while we currently don't know how to do such a network without being sure to who you are talking, I am wondering if there is some proof that we will never be able to know how to do that? So is there some inherent property which would as a consequence show that we have to trust somebody ultimately? (Maybe we have to trust them just partially, or just for a short periods of time, or maybe with some probability we can get good enough performance.) Only if the route is predictable and not in some way randomised. E.g. in Kad every step through the routing protocol gives you a choice of nodes to query next. The attacker would need to make sure he occupies all of those hot spots. Add some random walk during the initial routing phase, and costs for the attacker rise a lot more. Here, you are talking about an attacker targeting a particular route. I have more in mind an attacker who's goal is just to be disrupting the network enough so that people give up using it altogether. And if I understand correctly, I just have to spawn many man IDs and some of the routes (because of the Kademlia distance) will hit those IDs sooner or later. Anything that hits me, I drop. What will CJDNS have to do is to discover that anything send over one seemingly legitimate peer (a real ID) to any (or most, or many) of nodes behind the peer (fake nodes) is being dropped and then act in some way. How it will discover this, good question. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
Re: [liberationtech] CJDNS hype
Hi! On Sun, Jul 14, 2013 at 10:25 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Exactly. You don't have to black hole everything, just enough to make the network behave badly. Again though the physical reality of the network comes in to play. A physical reality in your case means the tunnels between nodes, not necessary the real-world physical distance? So you have tunnels between nodes and you assume that those tunnels are established based on some trust? And you route along the tunnels? I thought that you route along the Kademlia distance between keys of nodes. So if my key ID is closer to node B than to node C, I send packet to node B. And it does not matter how the tunnels are setup. It seems I misunderstood something then. This is then quite different than Kademlia. And from whitepaper: The address space distance between any two given addresses is defined as the of the result of the two addresses XOR'd against one another, rotated 64 bits, then interpreted as a big endian integer. So where does this definition of distance take into the account that there is trust between two addresses but no trust between some other two addresses? Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
Re: [liberationtech] CJDNS hype
Hi! On Sun, Jul 14, 2013 at 1:15 PM, Ralph Holz h...@net.in.tum.de wrote: Ah, I see. I was thinking more along the lines of how do I make sure I am not accidentally speaking to the censor himself?. As that would be as harmful as not being able to speak at all. Not necessary, if you still have end-to-end encryption. So transport layer should just assure transportation. BTW, how do you propose to make Sybil nodes impossible? I don't. I am just making an argument, that maybe there is some way we (or I) don't yet know which would allow us to don't have to trust other nodes with anything else that they forward the packet. And if they don't, we can maybe detect that and remove them from the routing path. So at the end maybe it is not even important if Sybil nodes are possible or impossible. You just care if they forward the packet. If they do, this is it. If they don't (from whatever reason, being malicious or just malperforming), you route along that, no? But to be able to route around, you have to be able to have multiple paths. So yes, while we currently don't know how to do such a network without being sure to who you are talking, I am wondering if there is some proof that we will never be able to know how to do that? So is there some inherent property which would as a consequence show that we have to trust somebody ultimately? (Maybe we have to trust them just partially, or just for a short periods of time, or maybe with some probability we can get good enough performance.) I am not so sure I understand what you mean, I am afraid. But generally speaking, it is very hard to quantify 'trust'. There is a host of literature on that, with trust metrics etc. I don't know much about that, except that I don't see it used anywhere. I was just saying that saying you need somebody you know and trust in the network implies one of two things: - we currently don't know how to do it otherwise, or - it is known that it is so and it will never be possible to do it otherwise (and is there a proof for that?) Although, if I were the censor, I'd go and censor the underlay. Do DPI on IP level and throttle (not block) by dropping 80% of all TCP segments. Just enough to let TCP retransmit all the time. Tor has been attacked (not throttled, blocked) that way on several occasions. I expect Jake and Roger will tell us more about that when they give their next talk. :) Yes. :-) BTW. The issue I have with you just have to make a security decision who you trust and then everything will work is that we have for quite some time very good and secure systems, where the only decision you have to do is a such one. And they fail again and again because people are very bad at determining this (phishing, for example). So saying that this is the only thing they should do for me is already a bit too much. We should find ways to make such decisions easier (in the browsers, we display warnings - and they are still not working always). And with schemes where your security decision does not just impact you, but also everybody else down your routing chain, this is even bigger problem. Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
Re: [liberationtech] CJDNS hype
On 07/14/2013 10:00 PM, Mitar wrote: Hi! On Sun, Jul 14, 2013 at 10:25 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: The most scary general attack on the idea is a node who drops 10% of the packets sent through them. I don't know how to detect it statelessly and they can do quite a bit of damage. Exactly. You don't have to black hole everything, just enough to make the network behave badly. If you blackhole everything then the network routes around you. The obvious example is when a node disconnects/reboots/etc. Again though the physical reality of the network comes in to play. A physical reality in your case means the tunnels between nodes, not necessary the real-world physical distance? So you have tunnels between nodes and you assume that those tunnels are established based on some trust? And you route along the tunnels? I thought that you route along the Kademlia distance between keys of nodes. So if my key ID is closer to node B than to node C, I send packet to node B. And it does not matter how the tunnels are setup. It seems I misunderstood something then. This is then quite different than Kademlia. And from whitepaper: The address space distance between any two given addresses is defined as the of the result of the two addresses XOR'd against one another, rotated 64 bits, then interpreted as a big endian integer. So where does this definition of distance take into the account that there is trust between two addresses but no trust between some other two addresses? It's similar to Virtual Ring Routing research.microsoft.com/pubs/75325/virtualring.pdf There is a physical network and a virtual DHT, it uses the DHT to find paths through the physical network and because the physical network is invite-only, most of the I'll connect 10,000 fake nodes type attacks just don't make sense. You'd need a botnet to attack the network because then you could have nodes spread out over physical space but clustered in keyspace. Thanks, Caleb Mitar -- 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
Re: [liberationtech] CJDNS hype
On Sun, Jul 14, 2013 at 8:28 PM, Caleb James DeLisle calebdeli...@lavabit.com wrote: You'd need a botnet to attack the network because then you could have nodes spread out over physical space but clustered in keyspace. And, presumably, convince people to connect to them. If I understood correctly? -- 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
Re: [liberationtech] CJDNS hype
Right, I didn't explain that well. It would be a botnet of machines which are already part of the cjdns network. Not something we have to worry about today or tomorrow but if it becomes a new defacto standard for the internet, it would be a concern. Thanks, Caleb On 07/15/2013 07:12 AM, Gregory Maxwell wrote: On Sun, Jul 14, 2013 at 8:28 PM, Caleb James DeLisle calebdeli...@lavabit.com wrote: You'd need a botnet to attack the network because then you could have nodes spread out over physical space but clustered in keyspace. And, presumably, convince people to connect to them. If I understood correctly? -- 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 -- 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
[liberationtech] CJDNS hype
Hi! I am a bit concerned with the CJDNS hype I am observing around. I do like that decentralized Internet is getting momentum, but I am concerned if CJDNS is really the way to achieve that. From its whitepaper it seems that it is susceptible to a Sybil attack: https://github.com/cjdelisle/cjdns/blob/master/rfcs/Whitepaper.md#the-router In fact, I very much share the concerns expressed here: http://mail.thefnf.org/pipermail/builders/2012-May/000544.html For me it seems far from something which would be resistant to any adversary trying to prevent communication from happening. It seems to me that it just ignores many of issues with DHTs and routing in overlay networks put out in research literature until today. Which is sometimes good because it can open paths to new ideas, but sometimes is just ignorant, especially if the main selling point of CJDNS is security and censorship resistance. Am I missing something? Has there been any security analysis of CJDNS? BTW, if you want to contribute to CJDNS project, there is a crowdfunding campaign happening: https://fund.meshwith.me/ Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
Re: [liberationtech] CJDNS hype
On Sat, Jul 13, 2013 at 12:36 PM, Mitar mmi...@gmail.com wrote: For me it seems far from something which would be resistant to any adversary trying to prevent communication from happening. It seems to me that it just ignores many of issues with DHTs and routing in overlay networks put out in research literature until today. Which is DHT's are basically a complete joke when it comes to attack resistance, and so it's with much face palming that I've endured near constant suggestions to Use a DHT!, often in completely inapplicable contexts, from people whos only exposure to distributed systems is DHTs. It's basically a running joke in the Bitcoin development community at this point. That said CJ is, in fact, aware of these issues— and CJDNS is at least intended to be resistant to sibyl attacks under some assumptions (I believe the main assumption is that you choose honest peers for your transport links (and that your honest peers also do so), because it isn't simply a topology blind DHT). The system is setup to require manual peering, so it isn't just a handwave— it's how you're expected to use it. (Now, how strong that requirement is isn't clear to me, e.g. how does your security fall off as a function of distance to honest nodes— or how realistic even the weakest form of that requirement is in practice, e.g. can even a spherical-technical-expert manage to reliably pick non-sybil peers— is another question.) Some of the other concerns about CJDNS is that its not— by itself— an anonymity network. Its anonymity properties are weaker than TOR's, for example. Though it may be the case that the composition of CJDNS and a high latency (/CBR) mix network might better address the spectrum of needs, there is still the risk that people may misunderstand what is actually being provided. -- 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
Re: [liberationtech] CJDNS hype
Hi! On Sat, Jul 13, 2013 at 1:15 PM, Gregory Maxwell gmaxw...@gmail.com wrote: That said CJ is, in fact, aware of these issues Are they described anywhere? There is nothing about that in the whitepaper: https://github.com/cjdelisle/cjdns/blob/master/rfcs/Whitepaper.md I would assume there would be a section on this and an analysis and conclusions? So that we could understand why they assume it is secure. Maybe I am missing something. — and CJDNS is at least intended to be resistant to sibyl attacks under some assumptions (I believe the main assumption is that you choose honest peers for your transport links (and that your honest peers also do so), because it isn't simply a topology blind DHT). From what I understand, it is a topology blind DHT. (Which makes me wonder why I see suggestions to use it for wireless mesh networks.) It takes Kademlia distance and then it routes to this next hop. So if I manage to populate the network with so many fake IDs which are so similar to anything people want to route over, I can black-hole all those packets going over me? The system is setup to require manual peering, so it isn't just a handwave— it's how you're expected to use it. So, web of trust is their security model for DHT? And isn't this a bit contrary to their idea that security should be easy and out of the box? So that users should just run CJDNS and should not have to make any security decision? Hm hm hm. Some of the other concerns about CJDNS is that its not— by itself— an anonymity network. Yes. I am not concerned about that. That's something it is written and said around about CJDNS. But what is also said is that the plan is to replace current internet infrastructure with a massive secure mesh network to prevent corporate and government censorship. And using Kademlia-based routing to prevent censorship seems a bit silly to me. But I think I don't understand something. One similar project in the past, if anybody is curious: https://en.wikipedia.org/wiki/Netsukuku Mitar -- http://mitar.tnode.com/ https://twitter.com/mitar_m -- 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
