July 2018 - cypherpunks-legacy

Teaching Cryptography to 5th graders
by Adam Aviv 06 Jul '18

06 Jul '18

I saw this post on Avi Rubin's blog today about his preparation for teaching a class of 5th graders cryptographic principles. http://avi-rubin.blogspot.com/2010/03/teaching-cryptography-to-5th-graders.… It is a nice post, and I thought the list would be interested despite the lack of eliptic curve cryptography in the lesson plan. I am at least excited to hear how it went. -- adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Teaching Cryptography to 5th graders
by Adam Aviv 06 Jul '18

06 Jul '18

I saw this post on Avi Rubin's blog today about his preparation for teaching a class of 5th graders cryptographic principles. http://avi-rubin.blogspot.com/2010/03/teaching-cryptography-to-5th-graders.… It is a nice post, and I thought the list would be interested despite the lack of eliptic curve cryptography in the lesson plan. I am at least excited to hear how it went. -- adam --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [serval-project-dev] Why wireless mesh networks wonbt save us from censorship
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

Hi Steve, Jeremy has already answered your questions well from a Serval perspective, but I offer my perspective as well. On Sun, Nov 27, 2011 at 8:22 PM, Song, Stephen <stephen.song(a)gmail.com> wrote: > On 27 November 2011 11:32, Jeremy Lakeman <jeremy(a)servalproject.org> wrote: >> "Reason 1: Management is hard and expensive." >> That's why we want a network that auto-discovers topology. And >> provides easy to use debugging information to assist in placement of >> additional nodes. > > I agree that there is lots of scope for improving this. B Computers > used to be hard to use and Apple has succeeded in making them stupidly > easy. B This can happen for mesh networks too. Absolutely agree here. Indeed, Serval has worked from the outset to make mesh telephony insanely simple to use, and I think we have made significant advances on the state ease of use and management of mesh networks in the process, with more innovation in the pipeline. >> "Reason 2: Omni-directional antennas suck. ... Reason 3: Your RF >> tricks wonbt help you here. ... Reason 4: Single-radio equipment >> doesnbt work; multi-radio equipment is very expensive." >> Fair enough. But we don't actually plan to build a wifi mesh network >> covering the globe. One un-censored connection to the internet is >> enough to join each little mesh network into the global internet. >> Store and forward; and wandering nodes may be enough to enable *some* >> communication in places where there isn't enough coverage yet for >> real-time traffic. Some communication is better than none. > > The directional versus omnidirectional debate is a bit of a > red-herring I think. B The author seems to be assuming that all > connections would be distant or at the edge of WiFi capacity. B If mesh > nodes are reasonably close you could actually consider turning the > radio power down as opposed to up which would reduce interference. > Also, there is no reason not to have a "directed" mesh where > semi-directional devices like nsIIs or similar cover an arc of a > community. B There are lots of creative things that can be done here > such as mesh segmenting, supernodes, etc. B Perhaps that would > disqualify them from being traditional mesh networks but who gives a > stuff about that? We agree heartily. Pure mesh networking fails in the way that a lot of other pure pursuits fail. But some judicious symmetry breaking can yield large dividends, and this is the approach we are already pursuing, e.g., by using the internet for backhaul when it is available. >> "Reason 5: Unplanned mesh networks break routing" >> Well, partly. Sure you're going to use bandwidth in order to compute >> routing paths. But I think this is not insurmountable. Definitely >> needs to be more work in this area though to ensure you avoid routing >> loops and black holes. And this is something that we are already >> researching and plan to tackle further. >> >> "unplanned wireless mesh networks never work at scale" >> Yep, there's an "event horizon" issue. If you spend too much bandwidth >> describing remote paths through the network, you'll have nothing left >> for actual data. So we absolutely need to limit the distribution of >> full topology information to ensure that local nodes can still >> communicate even if the greater mesh network is practically infinite. >> Beyond that limit you either interconnect via the internet, or we >> invent some other high level structure, address prefix / numbering >> scheme. > > So, from a Serval perspective this seems to be a good question. B If > the mesh protocol takes 1-2 minutes to "settle", how is it possible > for a mesh network based on moving mobile phones to update routes fast > enough to keep up. B Unless I miss something, the mesh routing is going > to be constantly playing catch up unless everyone stays still. We have some early work on very fast converging mesh networks in certain circumstances that we expect to map across at the right time. Basically, I have confidence that this can be substantially worked around. Also, the use of UHF/TVWS spectrum, low bit-rates and simple waveforms offers great potential to work around much of the problem in other creative ways, for example by switching voice calls to a very-long-range but very-low-bit-rate circuit, that would be capable of carrying a call over a single hop that would otherwise require perhaps half a dozen hops at higher bit-rate. Frequency hopping to make interference statistical is also a great help here. I am still writing up our initial plans in this space, and will make them public once we have a decent draft. > Have you guys done any testing of say 10 phones or more in a field > environment? As Jeremy has said, we have, and BATMAN has performed quite poorly. Part of this is really easy to fix, in that the link score calculation is slow to reflect lost links, and not fast enough to grab new good links. But we expect other interesting effects to emerge as we work on this. >> There are 2 billion(-ish) people out there with no affordable access >> to communications. This is absolutely a problem we should be >> dedicating time to solve. Not just to "fight Internet censorship", but >> to allow these people to be heard. > > Three unique problems: > > 1) B provide affordable communication infrastructure for those for whom > access is either unavailable or unaffordable, the so-called other > 2-3billion > 2) B provide resilient alternative communication infrastructure to > ensure that communication is not restricted by centralised control > 3) B provide easy-to-deploy infrastructure for use in crisis/disaster > relief scenario > > Mesh network infrastructure can potentially address all three of those > issue but your technology development priorities will change depending > on which one of the above is your mission. B Which one is Serval's > mission? I think I am inclined to agree with Jeremy that we see a common technology that is able to address all three fairly well. For example, (3) needs fool-proof deployment and management-free operation, but so does (1) and (2), but for different reasons. So we see the solution as requiring: - zero-configuration - tolerance of partitioning of the network - ability to scale, and maintain local operation when scaling beyond the bandwidth-limit event horizon. - security - use of existing phone numbers What differs for each use case is in some ways limited to how people use this platform, but fundamentally they all depend on the common ability of a phone to make/receive calls,sms,mms other data without recourse to infrastructure, and offering individuals the degree of privacy and security, and to some extent, the reliability, that people expect from a telephone network. Our Rhizome store-and-forward approach is a key element in all this, because it allows for almost insect-like persistence of retrying delivery, so that the instant a passage through the network becomes available it can be exploited. Also, Rhizome solves the nasty exponential bandwidth and arrival probability problem that otherwise hamstrings multi-hop wireless meshes. In fact, I would say that the fundamental reason why we think we (and this includes Village Telco) are able to make mesh networking work, is because we have focussed on a telephony-oriented model, where data volumes are lower, and where the user interface is simplified to telephone-level, which people understand, and which equally importantly, hides all of the mess underneath. It is also why we are not afraid of our planned overlay mesh network not being backward compatible for use by non-Serval-aware applications, as it will keep them from making inefficient and inconsiderate use of bandwidth, while allowing the use of the various innovations we have prototyped and have on the drawing board. On this note, we hope to be able to share a technology roadmap for the next 12 months in coming days. Paul. > Cheers... Steve > >> On Sun, Nov 27, 2011 at 7:17 PM, Alasdair Mclellan >> <alasdair(a)servalproject.org> wrote: >>> Hmm, >>> There are a bunch of good points in this article, but none of them take into >>> account the simple facts that; >>> 1) An unplanned mesh is better than nothing (and 'nothing' is our primary >>> use case), and >>> 2) Everyone has a handset. >>> Replacing the Internet with an unplanned mesh is, indeed, hard - especially >>> when you need a dedicated node type to do so. Using people's existing >>> handsets changes the game a bit (although exactly how much remains to be >>> seen). >>> Just my quick $0.02. >>> Cheers, >>> -- >>> Alasdair. >>> >>> On Sun, Nov 27, 2011 at 5:54 PM, Ben Hughes <ben(a)benrhughes.com> wrote: >>>> >>>> >>>> http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from… >>>> >>>> Via hackernews. Would be interested in hearing what tguys think, seeing as >>>> you have lots of real-world experience. >>>> >>>> Ben >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Serval Project Developers" group. >>>> To post to this group, send email to >>>> serval-project-developers(a)googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> serval-project-developers+unsubscribe(a)googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/serval-project-developers?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Serval Project Developers" group. >>> To post to this group, send email to >>> serval-project-developers(a)googlegroups.com. >>> To unsubscribe from this group, send email to >>> serval-project-developers+unsubscribe(a)googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/serval-project-developers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. >> To post to this group, send email to serval-project-developers(a)googlegroups.com. >> To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. >> >> > > > > -- > Steve Song > http://manypossibilities.net > http://villagetelco.org > > -- > You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. > To post to this group, send email to serval-project-developers(a)googlegroups.com. > To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. > For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [FoRK] Google
by rst＠ai.mit.edu 06 Jul '18

06 Jul '18

Lucas Gonze writes: > > P.S. Maybe I just hate the Google hype, of which there is much. > > The creepy all-seeing eye is what gets me. They can surely use my > verification email for gmail to cross-ref me to google groups, my blog, > and eventually all the way back to my ftp traces from the 80s. It hurts > to think about. I never understood why the privace fuss over gmail centered on their target ads. Use of tracking cookies across multiple Google services is a lot more worrisome. Playing with gmail without getting tracked is tricky at best -- last I checked, it just didn't work unless you took a search-tracking cookie as well. You could try to deal with that by setting up a browser profile with its own cookie jar, and using it for gmail and nothing else. But I think you'd still need a securely pseudonymous throwaway email address to set up the gmail account. And the lack of searches on that cookie would let them know, at least, that they're dealing with a privacy freak. FWIW, I'm really not sure what level of paranoia to adopt wrt Google. "Don't be evil" is a nice slogan, though "evil" is to some extent in the eye of the beholder. They don't seem too upset to put a few more bricks in the Great Firewall of China, for instance: http://news.zdnet.co.uk/internet/security/0,39020375,39167942,00.htm But that makes them no different from a lot other American companies, like Yahoo and Cisco, which have also been happy to cooperate, in their own ways. It's hard to make a case for Google as being uniquely evil or dangerous based so far on public misdeeds. But here, for what it's worth, is the most paranoid case I can easily concot. Suppose you were genuinely, unabashedly evil. And suppose you wanted to accumulate as much information as you could. (If people give you the information for free, so much the better). And suppose you wanted to get a lot of very smart people to make it easy to search and access that information for your nefarious purposes. (They, of course, wouldn't need to know what they are ultimately working on). You'd want access to everything at Google. But you wouldn't necessarily want to be up front and center promoting it in public. Better by far to let some genuine idealists be the public face -- while your agents quietly hang out inside, subverting the place. rst _______________________________________________ FoRK mailing list http://xent.com/mailman/listinfo/fork ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

Re: [serval-project-dev] Why wireless mesh networks wonbt save us from censorship
by Paul Gardner-Stephen 06 Jul '18

06 Jul '18

Hi Steve, Jeremy has already answered your questions well from a Serval perspective, but I offer my perspective as well. On Sun, Nov 27, 2011 at 8:22 PM, Song, Stephen <stephen.song(a)gmail.com> wrote: > On 27 November 2011 11:32, Jeremy Lakeman <jeremy(a)servalproject.org> wrote: >> "Reason 1: Management is hard and expensive." >> That's why we want a network that auto-discovers topology. And >> provides easy to use debugging information to assist in placement of >> additional nodes. > > I agree that there is lots of scope for improving this. B Computers > used to be hard to use and Apple has succeeded in making them stupidly > easy. B This can happen for mesh networks too. Absolutely agree here. Indeed, Serval has worked from the outset to make mesh telephony insanely simple to use, and I think we have made significant advances on the state ease of use and management of mesh networks in the process, with more innovation in the pipeline. >> "Reason 2: Omni-directional antennas suck. ... Reason 3: Your RF >> tricks wonbt help you here. ... Reason 4: Single-radio equipment >> doesnbt work; multi-radio equipment is very expensive." >> Fair enough. But we don't actually plan to build a wifi mesh network >> covering the globe. One un-censored connection to the internet is >> enough to join each little mesh network into the global internet. >> Store and forward; and wandering nodes may be enough to enable *some* >> communication in places where there isn't enough coverage yet for >> real-time traffic. Some communication is better than none. > > The directional versus omnidirectional debate is a bit of a > red-herring I think. B The author seems to be assuming that all > connections would be distant or at the edge of WiFi capacity. B If mesh > nodes are reasonably close you could actually consider turning the > radio power down as opposed to up which would reduce interference. > Also, there is no reason not to have a "directed" mesh where > semi-directional devices like nsIIs or similar cover an arc of a > community. B There are lots of creative things that can be done here > such as mesh segmenting, supernodes, etc. B Perhaps that would > disqualify them from being traditional mesh networks but who gives a > stuff about that? We agree heartily. Pure mesh networking fails in the way that a lot of other pure pursuits fail. But some judicious symmetry breaking can yield large dividends, and this is the approach we are already pursuing, e.g., by using the internet for backhaul when it is available. >> "Reason 5: Unplanned mesh networks break routing" >> Well, partly. Sure you're going to use bandwidth in order to compute >> routing paths. But I think this is not insurmountable. Definitely >> needs to be more work in this area though to ensure you avoid routing >> loops and black holes. And this is something that we are already >> researching and plan to tackle further. >> >> "unplanned wireless mesh networks never work at scale" >> Yep, there's an "event horizon" issue. If you spend too much bandwidth >> describing remote paths through the network, you'll have nothing left >> for actual data. So we absolutely need to limit the distribution of >> full topology information to ensure that local nodes can still >> communicate even if the greater mesh network is practically infinite. >> Beyond that limit you either interconnect via the internet, or we >> invent some other high level structure, address prefix / numbering >> scheme. > > So, from a Serval perspective this seems to be a good question. B If > the mesh protocol takes 1-2 minutes to "settle", how is it possible > for a mesh network based on moving mobile phones to update routes fast > enough to keep up. B Unless I miss something, the mesh routing is going > to be constantly playing catch up unless everyone stays still. We have some early work on very fast converging mesh networks in certain circumstances that we expect to map across at the right time. Basically, I have confidence that this can be substantially worked around. Also, the use of UHF/TVWS spectrum, low bit-rates and simple waveforms offers great potential to work around much of the problem in other creative ways, for example by switching voice calls to a very-long-range but very-low-bit-rate circuit, that would be capable of carrying a call over a single hop that would otherwise require perhaps half a dozen hops at higher bit-rate. Frequency hopping to make interference statistical is also a great help here. I am still writing up our initial plans in this space, and will make them public once we have a decent draft. > Have you guys done any testing of say 10 phones or more in a field > environment? As Jeremy has said, we have, and BATMAN has performed quite poorly. Part of this is really easy to fix, in that the link score calculation is slow to reflect lost links, and not fast enough to grab new good links. But we expect other interesting effects to emerge as we work on this. >> There are 2 billion(-ish) people out there with no affordable access >> to communications. This is absolutely a problem we should be >> dedicating time to solve. Not just to "fight Internet censorship", but >> to allow these people to be heard. > > Three unique problems: > > 1) B provide affordable communication infrastructure for those for whom > access is either unavailable or unaffordable, the so-called other > 2-3billion > 2) B provide resilient alternative communication infrastructure to > ensure that communication is not restricted by centralised control > 3) B provide easy-to-deploy infrastructure for use in crisis/disaster > relief scenario > > Mesh network infrastructure can potentially address all three of those > issue but your technology development priorities will change depending > on which one of the above is your mission. B Which one is Serval's > mission? I think I am inclined to agree with Jeremy that we see a common technology that is able to address all three fairly well. For example, (3) needs fool-proof deployment and management-free operation, but so does (1) and (2), but for different reasons. So we see the solution as requiring: - zero-configuration - tolerance of partitioning of the network - ability to scale, and maintain local operation when scaling beyond the bandwidth-limit event horizon. - security - use of existing phone numbers What differs for each use case is in some ways limited to how people use this platform, but fundamentally they all depend on the common ability of a phone to make/receive calls,sms,mms other data without recourse to infrastructure, and offering individuals the degree of privacy and security, and to some extent, the reliability, that people expect from a telephone network. Our Rhizome store-and-forward approach is a key element in all this, because it allows for almost insect-like persistence of retrying delivery, so that the instant a passage through the network becomes available it can be exploited. Also, Rhizome solves the nasty exponential bandwidth and arrival probability problem that otherwise hamstrings multi-hop wireless meshes. In fact, I would say that the fundamental reason why we think we (and this includes Village Telco) are able to make mesh networking work, is because we have focussed on a telephony-oriented model, where data volumes are lower, and where the user interface is simplified to telephone-level, which people understand, and which equally importantly, hides all of the mess underneath. It is also why we are not afraid of our planned overlay mesh network not being backward compatible for use by non-Serval-aware applications, as it will keep them from making inefficient and inconsiderate use of bandwidth, while allowing the use of the various innovations we have prototyped and have on the drawing board. On this note, we hope to be able to share a technology roadmap for the next 12 months in coming days. Paul. > Cheers... Steve > >> On Sun, Nov 27, 2011 at 7:17 PM, Alasdair Mclellan >> <alasdair(a)servalproject.org> wrote: >>> Hmm, >>> There are a bunch of good points in this article, but none of them take into >>> account the simple facts that; >>> 1) An unplanned mesh is better than nothing (and 'nothing' is our primary >>> use case), and >>> 2) Everyone has a handset. >>> Replacing the Internet with an unplanned mesh is, indeed, hard - especially >>> when you need a dedicated node type to do so. Using people's existing >>> handsets changes the game a bit (although exactly how much remains to be >>> seen). >>> Just my quick $0.02. >>> Cheers, >>> -- >>> Alasdair. >>> >>> On Sun, Nov 27, 2011 at 5:54 PM, Ben Hughes <ben(a)benrhughes.com> wrote: >>>> >>>> >>>> http://sha.ddih.org/2011/11/26/why-wireless-mesh-networks-wont-save-us-from… >>>> >>>> Via hackernews. Would be interested in hearing what tguys think, seeing as >>>> you have lots of real-world experience. >>>> >>>> Ben >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Serval Project Developers" group. >>>> To post to this group, send email to >>>> serval-project-developers(a)googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> serval-project-developers+unsubscribe(a)googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/serval-project-developers?hl=en. >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Serval Project Developers" group. >>> To post to this group, send email to >>> serval-project-developers(a)googlegroups.com. >>> To unsubscribe from this group, send email to >>> serval-project-developers+unsubscribe(a)googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/serval-project-developers?hl=en. >>> >> >> -- >> You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. >> To post to this group, send email to serval-project-developers(a)googlegroups.com. >> To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. >> >> > > > > -- > Steve Song > http://manypossibilities.net > http://villagetelco.org > > -- > You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. > To post to this group, send email to serval-project-developers(a)googlegroups.com. > To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. > For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Serval Project Developers" group. To post to this group, send email to serval-project-developers(a)googlegroups.com. To unsubscribe from this group, send email to serval-project-developers+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/serval-project-developers?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

the physics arXiv blog
by the physics arXiv blog 06 Jul '18

06 Jul '18

[1]the physics arXiv blog [2]Calculating the cost of dirty bombs Posted: 24 Feb 2009 09:46 PM PST cesium-137 One of the more frightening scenarios that civil defence teams worry about is the possibility that a bomb contaminated with radioactive material would be detonated in a heavily populated area. Various research teams have considered this problem and come to similar conclusions-that the actual threat to human health from such a device is low. Some even claim that terror groups must have come to a similar conclusion which is why we've not been on the receiving end of such an attack. The panic such a device would cause is another questions. Today Theodore Liolios from a private institution called the Hellenic Arms Control Center in Thessaloniki in Greece, goes through the figures. He says the most likely material to be used in such an attack is Cesium-137, widely used throughout the developed and developing world as a source for medical therapies. The unstated implication is that it would be relatively easy to get hold of this stuff from a poorly guarded hospital. Exactly this happened in Goiania in Brazil when an abandoned hospital was broken into and its supply of cesium-137 distributed around the surrounding neighbourhoods. The incident left 200 people contaminated. Four of them died. But a dirty bomb would not be nearly as lethal. The trouble with them (from a terrorist's point of view, at least) is that distributing radioactive material over a large area dramatically reduces the exposure that people receive. Particularly when most could be warned to stay indoors or be evacuated (unlike the Goiania incident in which most people were unaware they were contaminated). Liolios calculates that anybody within a 300 metre range of a dirty bomb would increase their lifetime risk of cancer mortality by about 1.5 per cent. And then only if they were unable to take shelter or leave the area. That's about 280 people given the kind of densities you expect in metropolitan areas. And he goes on to say that it is reasonable to assume that a cesium-137 dirty bomb would not increase the cancer mortality risk for the entire city by a statistically significant amount. But the terror such a device might cause is another question. Liolios reckons that current radiation safety standards would mean the evacuation of some 78 square kilometres around ground zero. That would affect some 78,000 people, cost $7.8m per day to evacuate and some $78m to decontaminate. That seems a tad conservative but however it is calculated, it may turn out to be chickenfeed compared to the chaos caused by panic, which may well result in more deaths than the bomb itself could claim. How to calculate the effect of that? Ref: [3]arxiv.org/abs/0902.3789: The Effects of Using Cesium-137 Teletherapy Sources as a Radiological Weapon [4][ISMAP:i] [5][arXivblog?d=41] [6][arXivblog?d=43] [7][arXivblog?i=q0kESIfp] [8][arXivblog?d=50] [9][arXivblog?i=qYq6tyZu] [10][arXivblog?d=54] [11][arXivblog?i=yYhXfdor] [12][arXivblog?d=52] You are subscribed to email updates from [13]the physics arXiv blog To stop receiving these emails, you may [14]unsubscribe now. Email delivery powered by Google Inbox too full? [15](feed) [16]Subscribe to the feed version of the physics arXiv blog in a feed reader. If you prefer to unsubscribe via postal mail, write to: the physics arXiv blog, c/o Google, 20 W Kinzie, Chicago IL USA 60610 References 1. http://arxivblog.com/ 2. http://feedproxy.google.com/~r/arXivblog/~3/EyJUW8qEyis/ 3. http://arxiv.org/abs/0902.3789 4. https://feedads.googleadservices.com/~a/1ni-jO1OpBXTAVHGF__2ozz9FV4/a 5. http://feeds2.feedburner.com/~f/arXivblog?a=gJx2anXh 6. http://feeds2.feedburner.com/~f/arXivblog?a=SSnm0QJ1 7. http://feeds2.feedburner.com/~f/arXivblog?a=q0kESIfp 8. http://feeds2.feedburner.com/~f/arXivblog?a=fEaGwZnF 9. http://feeds2.feedburner.com/~f/arXivblog?a=qYq6tyZu 10. http://feeds2.feedburner.com/~f/arXivblog?a=aYao85i8 11. http://feeds2.feedburner.com/~f/arXivblog?a=yYhXfdor 12. http://feeds2.feedburner.com/~f/arXivblog?a=FmM6bNAk 13. http://arxivblog.com/ 14. http://feedburner.google.com/fb/a/mailunsubscribe?k=118r9-S4Z0vJg-AkQPASPmD… 15. http://feeds2.feedburner.com/arXivblog 16. http://feeds2.feedburner.com/arXivblog ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

the physics arXiv blog
by the physics arXiv blog 06 Jul '18

06 Jul '18

[1]the physics arXiv blog [2]Calculating the cost of dirty bombs Posted: 24 Feb 2009 09:46 PM PST cesium-137 One of the more frightening scenarios that civil defence teams worry about is the possibility that a bomb contaminated with radioactive material would be detonated in a heavily populated area. Various research teams have considered this problem and come to similar conclusions-that the actual threat to human health from such a device is low. Some even claim that terror groups must have come to a similar conclusion which is why we've not been on the receiving end of such an attack. The panic such a device would cause is another questions. Today Theodore Liolios from a private institution called the Hellenic Arms Control Center in Thessaloniki in Greece, goes through the figures. He says the most likely material to be used in such an attack is Cesium-137, widely used throughout the developed and developing world as a source for medical therapies. The unstated implication is that it would be relatively easy to get hold of this stuff from a poorly guarded hospital. Exactly this happened in Goiania in Brazil when an abandoned hospital was broken into and its supply of cesium-137 distributed around the surrounding neighbourhoods. The incident left 200 people contaminated. Four of them died. But a dirty bomb would not be nearly as lethal. The trouble with them (from a terrorist's point of view, at least) is that distributing radioactive material over a large area dramatically reduces the exposure that people receive. Particularly when most could be warned to stay indoors or be evacuated (unlike the Goiania incident in which most people were unaware they were contaminated). Liolios calculates that anybody within a 300 metre range of a dirty bomb would increase their lifetime risk of cancer mortality by about 1.5 per cent. And then only if they were unable to take shelter or leave the area. That's about 280 people given the kind of densities you expect in metropolitan areas. And he goes on to say that it is reasonable to assume that a cesium-137 dirty bomb would not increase the cancer mortality risk for the entire city by a statistically significant amount. But the terror such a device might cause is another question. Liolios reckons that current radiation safety standards would mean the evacuation of some 78 square kilometres around ground zero. That would affect some 78,000 people, cost $7.8m per day to evacuate and some $78m to decontaminate. That seems a tad conservative but however it is calculated, it may turn out to be chickenfeed compared to the chaos caused by panic, which may well result in more deaths than the bomb itself could claim. How to calculate the effect of that? Ref: [3]arxiv.org/abs/0902.3789: The Effects of Using Cesium-137 Teletherapy Sources as a Radiological Weapon [4][ISMAP:i] [5][arXivblog?d=41] [6][arXivblog?d=43] [7][arXivblog?i=q0kESIfp] [8][arXivblog?d=50] [9][arXivblog?i=qYq6tyZu] [10][arXivblog?d=54] [11][arXivblog?i=yYhXfdor] [12][arXivblog?d=52] You are subscribed to email updates from [13]the physics arXiv blog To stop receiving these emails, you may [14]unsubscribe now. Email delivery powered by Google Inbox too full? [15](feed) [16]Subscribe to the feed version of the physics arXiv blog in a feed reader. If you prefer to unsubscribe via postal mail, write to: the physics arXiv blog, c/o Google, 20 W Kinzie, Chicago IL USA 60610 References 1. http://arxivblog.com/ 2. http://feedproxy.google.com/~r/arXivblog/~3/EyJUW8qEyis/ 3. http://arxiv.org/abs/0902.3789 4. https://feedads.googleadservices.com/~a/1ni-jO1OpBXTAVHGF__2ozz9FV4/a 5. http://feeds2.feedburner.com/~f/arXivblog?a=gJx2anXh 6. http://feeds2.feedburner.com/~f/arXivblog?a=SSnm0QJ1 7. http://feeds2.feedburner.com/~f/arXivblog?a=q0kESIfp 8. http://feeds2.feedburner.com/~f/arXivblog?a=fEaGwZnF 9. http://feeds2.feedburner.com/~f/arXivblog?a=qYq6tyZu 10. http://feeds2.feedburner.com/~f/arXivblog?a=aYao85i8 11. http://feeds2.feedburner.com/~f/arXivblog?a=yYhXfdor 12. http://feeds2.feedburner.com/~f/arXivblog?a=FmM6bNAk 13. http://arxivblog.com/ 14. http://feedburner.google.com/fb/a/mailunsubscribe?k=118r9-S4Z0vJg-AkQPASPmD… 15. http://feeds2.feedburner.com/arXivblog 16. http://feeds2.feedburner.com/arXivblog ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [cryptography] OTR and deniability
by Steven Bellovin 06 Jul '18

06 Jul '18

The two Ian G's have it correct: while OTR provides (some level of) lack of evidence within the system, it says nothing about external evidence like netflow records, which machine the logs were taken from, etc. To pick one bad example -- bad because I don't know if it fits the facts of this case -- if one party to a purported conversation turned over a log file, and forensic examination of the second party's computer showed the same log, I suspect that most people would believe that those two parties had that conversation. Of course, the authenticity of the log files could be challenged -- did the first party hack into the second party's computer and plant the log file? had someone else hacked into it and used it to talk with the first party? -- but that's also outside the crypto protocol. Put another way, the goal in a trial is not a mathematical proof, it's proof to a certain standard of evidence, based on many different pieces of data. Life isn't a cryptographic protocol. --Steve Bellovin, https://www.cs.columbia.edu/~smb _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

<nettime> The Wikileaks Stratfor Case
by Geert Lovink 06 Jul '18

06 Jul '18

WikiLeaks mystery press conference Monday 12 noon, Frontline Club, Paddington, London, 13 Norfolk place W2 1QJ. WL press release: The Global Intelligence Files http://wlcentral.org/node/2474 On the 27th of February 2012, Wikileaks released the following statement: LONDONB- Today, Monday 27 February, WikiLeaks began publishing The Global Intelligence Files b more than five million emails from the Texas-headquartered "global intelligence" company Stratfor. The emails date from between July 2004 and late December 2011. They reveal the inner workings of a company that fronts as an intelligence publisher, but provides confidential intelligence services to large corporations, such as Bhopalbs Dow Chemical Co., Lockheed Martin, Northrop Grumman, Raytheon and government agencies, including the US Department of Homeland Security, the US Marines and the US Defense Intelligence Agency. The emails show Stratforbs web of informers, pay-off structure, payment-laundering techniques and psychological methods, for example: "You have to take control of him. Control means financial, sexual or psychological control... This is intended to start our conversation on your next phase" b CEO George Friedman to Stratfor analyst Reva Bhalla on 6 December 2011, on how to exploit an Israeli intelligence informant providing information on the medical condition of the President of Venezuala, Hugo Chavez." The material contains privileged information about the US governmentbs attacks against Julian Assange and WikiLeaks and Stratforbs own attempts to subvert WikiLeaks. There are more than 4,000 emails mentioning WikiLeaks or Julian Assange. The emails also expose the revolving door that operates in private intelligence companies in the United States. Government and diplomatic sources from around the world give Stratfor advance knowledge of global politics and events in exchange for money. The Global Intelligence Files exposes how Stratfor has recruited a global network of informants who are paid via Swiss banks accounts and pre-paid credit cards. Stratfor has a mix of covert and overt informants, which includes government employees, embassy staff and journalists around the world. The material shows how a private intelligence agency works, and how they target individuals for their corporate and government clients. For example, Stratfor monitored and analysed the online activities of Bhopal activists, including the "Yes Men", for the US chemical giant Dow Chemical. The activists seek redress for the 1984 Dow Chemical/Union Carbide gas disaster in Bhopal, India. The disaster led to thousands of deaths, injuries in more than half a million people, and lasting environmental damage. Stratfor has realised that its routine use of secret cash bribes to get information from insiders is risky. In August 2011, Stratfor CEO George Friedman confidentially told his employees: "We are retaining a law firm to create a policy for Stratfor on the Foreign Corrupt Practices Act. I donbt plan to do the perp walk and I donbt want anyone here doing it either." Stratforbs use of insiders for intelligence soon turned into a money-making scheme of questionable legality. The emails show that in 2009 then-Goldman Sachs Managing Director Shea Morenz and Stratfor CEO George Friedman hatched an idea to "utilise the intelligence" it was pulling in from its insider network to start up a captive strategic investment fund. CEO George Friedman explained in a confidential August 2011 document, marked DO NOT SHARE OR DISCUSS: "What StratCap will do is use our Stratforbs intelligence and analysis to trade in a range of geopolitical instruments, particularly government bonds, currencies and the like". The emails show that in 2011 Goldman Sachbs Morenz invested "substantially" more than $4million and joined Stratforbs board of directors. Throughout 2011, a complex offshore share structure extending as far as South Africa was erected, designed to make StratCap appear to be legally independent. But, confidentially, Friedman told StratFor staff: "Do not think of StratCap as an outside organisation. It will be integral... It will be useful to you if, for the sake of convenience, you think of it as another aspect of Stratfor and Shea as another executive in Stratfor... we are already working on mock portfolios and trades". StratCap is due to launch in 2012. The Stratfor emails reveal a company that cultivates close ties with US government agencies and employs former US government staff. It is preparing the 3-year Forecast for the Commandant of the US Marine Corps, and it trains US marines and "other government intelligence agencies" in "becoming government Stratfors". Stratforbs Vice-President for Intelligence, Fred Burton, was formerly a special agent with the US State Departmentbs Diplomatic Security Service and was their Deputy Chief of the counterterrorism division. Despite the governmental ties, Stratfor and similar companies operate in complete secrecy with no political oversight or accountability. Stratfor claims that it operates "without ideology, agenda or national bias", yet the emails reveal private intelligence staff who align themselves closely with US government policies and channel tips to the Mossad b including through an information mule in the Israeli newspaper Haaretz, Yossi Melman, who conspired with Guardian journalist David Leigh to secretly, and in violation of WikiLeaksb contract with the Guardian, move WikiLeaks US diplomatic cables to Israel. Ironically, considering the present circumstances, Stratfor was trying to get into what it called the leak-focused 'gravy train' that sprung up after WikiLeaksb Afghanistan disclosures: "Is it possible for us to get some of that bleak-focusedb gravy train? This is an obvious fear sale, so thatbs a good thing. And we have something to offer that the IT security companies donbt, mainly our focus on counter-intelligence and surveillance that Fred and Stick know better than anyone on the planet... Could we develop some ideas and procedures on the idea of B4leak-focusedb network security that focuses on preventing onebs own employees from leaking sensitive information... In fact, Ibm not so sure this is an IT problem that requires an IT solution." Like WikiLeaksb diplomatic cables, much of the significance of the emails will be revealed over the coming weeks, as our coalition and the public search through them and discover connections. Readers will find that whereas large numbers of Stratforbs subscribers and clients work in the US military and intelligence agencies, Stratfor gave a complimentary membership to the controversial Pakistan general Hamid Gul, former head of Pakistanbs ISI intelligence service, who, according to US diplomatic cables, planned an IED attack on international forces in Afghanistan in 2006. Readers will discover Stratforbs internal email classification system that codes correspondence according to categories such as balphab, btacticalb and bsecureb. The correspondence also contains code names for people of particular interest such as bIzziesb (members of Hezbollah), or bAdoggb (Mahmoud Ahmedinejad). Stratfor did secret deals with dozens of media organisations and journalists b from Reuters to the Kiev Post. The list of Stratforbs 'Confederation Partners' whom Stratfor internally referred to as its 'Confed Fuck House' are included in the release. While it is acceptable for journalists to swap information or be paid by other media organisations, because Stratfor is a private intelligence organisation that services governments and private clients these relationships are corrupt or corrupting. WikiLeaks has also obtained Stratforbs list of informants and, in many cases, records of its payoffs, including $1,200 a month paid to the informant 'Geronimo', handled by Stratforbs Former State Department agent Fred Burton. WikiLeaks has built an investigative partnership with more than 25 media organisations and activists to inform the public about this huge body of documents. The organisations were provided access to a sophisticated investigative database developed by WikiLeaks and together with WikiLeaks are conducting journalistic evaluations of these emails. Important revelations discovered using this system will appear in the media in the coming weeks, together with the gradual release of the source documents Also named are the main press partners working on this release: - Al Akhbar b Lebanon b http://english.al-akhbar.com - Al Masry Al Youm b Egypt b http://www.almasry-alyoum.com - Bivol b Bulgaria b http://bivol.bg - CIPER b Chile b http://ciperchile.cl - Dawn Media b Pakistan b http://www.dawn.com - LbEspresso b Italy b http://espresso.repubblica.it - La Repubblica b Italy b http://www.repubblica.it - La Jornada b Mexico b www.jornada.unam.mx/ - La Nacion b Costa Rica b http://www.nacion.com - Malaysia Today b Malaysia b www.malaysia-today.net - McClatchy b United States b http://www.mcclatchy.com - Nawaat b Tunisia b http://nawaat.org - NDR/ARD b Germany b http://www.ndr.de - Owni b France b http://owni.fr - Pagina 12 b Argentina b www.pagina12.com.ar - Plaza Publica b Guatemala b http://plazapublica.com.gt - Publico.es b Spain b www.publico.es - Rolling Stone b United States b http://www.rollingstone.com - Russia Reporter b Russia b http://rusrep.ru - Ta Nea b Greece b- http://www.tanea.gr - Taraf b Turkey b http://www.taraf.com.tr - The Hindu b India b www.thehindu.com - The Yes Men b Bhopal Activists b Global http://theyesmen.org - Nicky Hager for NZ Herald b New Zealand b http://www.nzherald.co.nz A press conference is going to take place at noon at the Frontline Club in central London. The first press coverage to be announced appeared on Publico.es. # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [DIYbio] Re: Lethal Bird Flu Transmission Among Humans Now Possible Thanks to Biochemists
by ruphos 06 Jul '18

06 Jul '18

On Fri, Jun 1, 2012 at 1:31 PM, EJ <ellenjorgensen(a)aol.com> wrote: > According to articles in Nature and Science, the thing that tipped the > scales in favor of publication was the discovery of natural flu variants > that were halfway towards the full complement of mutations necessary for > increased transmission. Who was so reckless to let that information slip? Now all those 'Merica-hating terrorists will be out stealing used tissues to get a jump on the game! -- "And if ye cannot be saints of knowledge, then be at least its warriors." -- Friedrich Nietzsche -- You received this message because you are subscribed to the Google Groups "DIYbio" group. To post to this group, send email to diybio(a)googlegroups.com. To unsubscribe from this group, send email to diybio+unsubscribe(a)googlegroups.com. For more options, visit this group at http://groups.google.com/group/diybio?hl=en. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0