Re: [liberationtech] FreedomHack hackathon in DC to build tools for citizen reporters in Mexico
Virtual would be good. This is a specific area of interest and research for me, and I would like to find a way to collaborate securely with others. On Aug 1, 2013 4:51 AM, "Kirby Plessas" wrote: > I'm not the organizer of this event, but I am sure it will go beyond > DC-based events. I believe this is the CommunityRED kick off event and it > is in DC because the founder, Shauna Dillavou, is here and she is > partnering with some other DC orgs. I've let her know about libtech and > hopefully she will join soon to talk about it. > > Were you thinking other city-based hackathons or maybe a virtual one? > > > Kirby Plessas > President and CEO > Plessas Experts Network, Inc. > 202-684-8101 > 202-403-3528 (fax) > > > On Wed, Jul 31, 2013 at 10:20 AM, Kyle Maxwell wrote: > >> Do you have plans for future efforts to include non-DC-located hackers? >> >> On Wed, Jul 31, 2013 at 9:05 AM, Kirby Plessas wrote: >> > FreedomHack is a hackathon put together by CommunityRED along with >> Amnesty >> > International and Cont3nt.com with the aim of building digital tools to >> aid >> > citizen reporters in Mexico. Mexico is consistently rated as one of the >> most >> > dangerous places in the world for reporters, due to violence and >> targeting >> > from drug cartels. The tools developed during FreedomHack will >> capitalize on >> > existing open source goodness to help journalists report stories >> anonymously >> > and securely - a total necessity for more reporting of corruption in >> > government and cartel-related violence. >> > >> > >> > This is an excellent opportunity to launch the good work of >> CommunityRED, >> > which provides digital safety for journalists, activists, and citizen >> > journalists in conflict zones. If you like open source stuff, tech for >> good, >> > or just plain doing good, come join us! >> > >> > >> > Oh yeah, use this link for a 100% discount: >> > http://freedomhack.eventbrite.com/?discount=TLM4EVER >> > >> > (It's free! Of course.) >> > >> > -- >> > 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 >> > > > -- > 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 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
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
[liberationtech] Surtr: Malware Family Targeting the Tibetan Community
Hi Libtech Katie Kleemola (Security Analyst, Citizen Lab) and Seth Hardy (Senior Security Analyst, Citizen Lab) have just released a new blog post "Surtr: Malware Family Targeting the Tibetan Community" As part of our ongoing study into targeted attacks on human rights groups and civil society organizations, the Citizen Lab analyzed a malicious email sent to Tibetan organizations in June 2013. The email in question purported to be from a prominent member of the Tibetan community and repurposed content from a community mailing list. Attached to the email were what appeared to be three Microsoft Word documents (.doc), but which were trojaned with a malware family we call “Surtr” . All three attachments drop the exact same malware. We have seen the Surtr malware family used in attacks on Tibetan groups dating back to November 2012. This blog post details technical charatectiscs of the malware family and shares MD5s and identifiers See the full post here: https://citizenlab.org/2013/08/surtr-malware-family-targeting-the-tibetan-community/ -- Masashi Nishihata Research Manager, Citizen Lab Munk School of Global Affairs University of Toronto Phone: (416) 946-8903 pgp key: https://citizenlab.org/masashi-key.txt -- 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
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
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 dif
