July 2018 - cypherpunks-legacy

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

06 Jul '18

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. Computers used to be hard to use and Apple has succeeded in making them stupidly easy. This can happen for mesh networks too. > "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. The author seems to be assuming that all connections would be distant or at the edge of WiFi capacity. 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. There are lots of creative things that can be done here such as mesh segmenting, supernodes, etc. Perhaps that would disqualify them from being traditional mesh networks but who gives a stuff about that? > "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. 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. Unless I miss something, the mesh routing is going to be constantly playing catch up unless everyone stays still. Have you guys done any testing of say 10 phones or more in a field environment? > 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) provide affordable communication infrastructure for those for whom access is either unavailable or unaffordable, the so-called other 2-3billion 2) provide resilient alternative communication infrastructure to ensure that communication is not restricted by centralised control 3) 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. Which one is Serval's mission? 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. ----- 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 Song, Stephen 06 Jul '18

06 Jul '18

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. Computers used to be hard to use and Apple has succeeded in making them stupidly easy. This can happen for mesh networks too. > "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. The author seems to be assuming that all connections would be distant or at the edge of WiFi capacity. 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. There are lots of creative things that can be done here such as mesh segmenting, supernodes, etc. Perhaps that would disqualify them from being traditional mesh networks but who gives a stuff about that? > "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. 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. Unless I miss something, the mesh routing is going to be constantly playing catch up unless everyone stays still. Have you guys done any testing of say 10 phones or more in a field environment? > 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) provide affordable communication infrastructure for those for whom access is either unavailable or unaffordable, the so-called other 2-3billion 2) provide resilient alternative communication infrastructure to ensure that communication is not restricted by centralised control 3) 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. Which one is Serval's mission? 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. ----- 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: [p2p-hackers] Pirate Pay
by Vijay K. Gurbani 06 Jul '18

06 Jul '18

On 05/14/2012 10:44 AM, David Barrett wrote: > Oh interesting, so it's attacking the DHT layer in addition to the > Torrent layer? Clever! > > In the torrent layer, any individual torrent client is able to > gradually weed out bad actors by identifying slow transfer speeds > and/or high rates of hash mismatches. But I'm not familiar with the > details of the public torrent DHT -- do individual nodes have any > protections in place to identify and ignore bad nodes? Bittorrent DHT is based on Kademlia, and I am not an expert on Kademlia (I will let my colleagues whose paper [2] I mentioned earlier speak out as experts). But, it seems to me that once the sybils have made themselves responsible for the resource, they can selectively include good peers but in smaller numbers so as to keep the rate of successful downloads low. So the point is not to completely stop downloading but to impact it enough that a majority of downloaders fail. A snipped from a follow-up interview of Pirate Pay's founders appear to support this [1]: "We used a number of servers to make a connection to each and every p2p client that distributed this film. Then Pirate Pay sent specific traffic to confuse these clients about the real I.P. addresses of other clients and to make them disconnect from each other,b Andrei Klimenko said. b Not all the goals were reached. But nearly 50,000 users did not complete their downloads." > Though I imagine the cost to wage this attack is greater than the > benefit obtained, so the most likely (and most effective) response is > probably "do nothing". The analysis by Varvello and Steiner [2] indicated that 3 or 8 sybils are enough to command an info hash. I suspect that the cost, then, from Pirate Pay's point of view is low and the perceived payoff high. [1] http://rbth.ru/articles/2012/05/10/russian_innovators_pursue_prototype_to_p… [2] http://www.moritzsteiner.de/papers/dht_traffic_localization.pdf Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg(a){bell-labs.com,acm.org} / vijay.gurbani(a)alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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: [p2p-hackers] Pirate Pay
by Vijay K. Gurbani 06 Jul '18

06 Jul '18

On 05/14/2012 10:44 AM, David Barrett wrote: > Oh interesting, so it's attacking the DHT layer in addition to the > Torrent layer? Clever! > > In the torrent layer, any individual torrent client is able to > gradually weed out bad actors by identifying slow transfer speeds > and/or high rates of hash mismatches. But I'm not familiar with the > details of the public torrent DHT -- do individual nodes have any > protections in place to identify and ignore bad nodes? Bittorrent DHT is based on Kademlia, and I am not an expert on Kademlia (I will let my colleagues whose paper [2] I mentioned earlier speak out as experts). But, it seems to me that once the sybils have made themselves responsible for the resource, they can selectively include good peers but in smaller numbers so as to keep the rate of successful downloads low. So the point is not to completely stop downloading but to impact it enough that a majority of downloaders fail. A snipped from a follow-up interview of Pirate Pay's founders appear to support this [1]: "We used a number of servers to make a connection to each and every p2p client that distributed this film. Then Pirate Pay sent specific traffic to confuse these clients about the real I.P. addresses of other clients and to make them disconnect from each other,b Andrei Klimenko said. b Not all the goals were reached. But nearly 50,000 users did not complete their downloads." > Though I imagine the cost to wage this attack is greater than the > benefit obtained, so the most likely (and most effective) response is > probably "do nothing". The analysis by Varvello and Steiner [2] indicated that 3 or 8 sybils are enough to command an info hash. I suspect that the cost, then, from Pirate Pay's point of view is low and the perceived payoff high. [1] http://rbth.ru/articles/2012/05/10/russian_innovators_pursue_prototype_to_p… [2] http://www.moritzsteiner.de/papers/dht_traffic_localization.pdf Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg(a){bell-labs.com,acm.org} / vijay.gurbani(a)alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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: [liberationtech] Privacy, data protection questions
by Rich Kulawiec 06 Jul '18

06 Jul '18

On Fri, Mar 22, 2013 at 09:58:17AM -0500, Andrew Haeg wrote: > We're in the late prototype phase for Groundsource<http://groundsourcing.com>, > a mobile data collection and engagement platform -- designed for > journalists, researchers, NGO's and others to use to gather first-hand > knowledge. We've used the prototype to validate the need for the > platform, and now privacy & data protection have moved front and center as > we ramp up for a beta phase later this spring/summer. > > We've had some early discussions with the Tor Project about protecting > journalists using the platform in countries with repressive regimes (down > the road). We're also looking into using Wickr for encrypting > communications. In the short term, we need advisors who can help guide our > decisions around privacy and personal data collection & protection. Ok. Here's some advice. You're not going to like it. ;-) Sorry. But better now than later, when lives are on the line. I'd like to ask you to open a web browser and use your favorite search engine to search for: mobile malware epidemic smartphone malware android malware windows phone malware and similar. Then I'd like you to explain how you propose to keep all those mobile phones secure in the face of routine malware, let alone targeted and custom malware crafted by hostile governments who would very much like all those journalists and researchers and NGOs you mentioned to STFU because they're saying and reporting and doing things those governments find...disturbing. Forget all the other security and privacy issues for a moment (some of which I touched on in a previous list message [1]): how, EXACTLY, do you propose to keep those phones from being infested just like a gazillion other phones already are or will be real soon now? Because once those endpoints are compromised, all the crafty routing and anonymization and encryption layers you could possibly put in place aren't going to matter very much. And those endpoints WILL be compromised (probably much sooner than you think) because they're going to be in the hands of journalists and researchers and NGOs, *not* in the hands of paranoid clueful paranoid diligent (did I mention paranoid?) geeks. Oh, sure, someone sufficiently knowledgeable, cautious, etc. can probably keep *one* phone secure. Just like someone with those qualities might be able to keep a single Windows system secure. There are people on this list who are capable of both of those things. But dozens? Hundreds? Thousands? Being carried around all over the place by their owners? There's not a chance in hell. None. This is not a solved problem in computing. Nor is there even a hint of a twitch of a notion of a suggestion of a whisper that it will be solved anytime soon. It's not even solved for people who've stacked the deck in their favor (e.g., those who have the luxury of centralized control) let alone for those who are allowing end users to connect their own. And most of them aren't painting big targets on their chests, they're just caught up in the general crossfire...unlike *your* users, who are self-nominating to be on the business end of some very serious attention from some very determined, clueful and nasty people -- people who probably *already* have been working on building or buying custom malware for phones because of course that's what any prudent adversary with sufficient resources would be doing just about now. Yeah, okay, so I'm making the point at your expense, and I don't really mean to do that, so I'll make it in the more general case: look, people, unless you can produce a plan -- and more than that, a plan that's been proven in the field to work -- for keeping, let's say, a population of, oh, a thousand independent scattered phones free of malware, then you CAN'T deploy your whizbang singing dancing smartphone app because it's going to be promptly undermined. Any government worthy of the term "oppressive" is going to 0wn each and every phone of interest and is going to install trackers, spyware, keystroke loggers, and whatever else occurs to them, and you're not going to stop them. At best, you might figure out that this is happening after-the-fact and remediate some of them...until they go back out in the field and get infested again. Lather, rinse, repeat. Not to put too fine a point on it (but I suppose I will anyway): If someone else can run arbitrary code on your computer, it's not YOUR computer any more. [2] The phone may be in a journalist's hand or it may be in a researcher's pocket, but it's not theirs. *Not any more*. Which means that your liberation app, the one that you designed and developed and sweated over, the one that your user is trusting to send and receive sensitive information, the one that's connecting to a backend through umpteen layers of encryption and obfuscation and misdirection and whatever...is now running on the government's phone. ---rsk [1] https://mailman.stanford.edu/pipermail/liberationtech/2013-March/007672.html [2] I'm probably quoting somebody. But I don't know who. -- Too many emails? Unsubscribe, change to digest, or change password by emailing moderator at companys(a)stanford.edu or changing your settings at https://mailman.stanford.edu/mailman/listinfo/liberationtech ----- 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

None
by None 06 Jul '18

06 Jul '18

up.net X-Spam-Level:=20 X-Spam-Pyzor: Reported 0 times. X-Spam-Status: No, score=3D-2.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES= _00, CK_419SIZE,DKIM_SIGNED,ENV_FROM_DIFF0,FORWARD_RELAY, HEADER_FROM_DIFFERENT_DOMAINS,MAILPHISH4,ODD_PUNCTUATION2,RCVD_IN_DNSWL_= LOW, SPF_HELO_PASS,T_DKIM_INVALID shortcircuit=3Dno autolearn=3Ddisabled vers= ion=3D3.4.0 Delivered-To: rayzer(a)riseup.net Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure S= erver CA" (verified OK)) by spoonbill.riseup.net (Postfix) with ESMTPS id 25A8C238; Thu, 8 Oct 2015 17:52:52 +0000 (UTC) Received: from antiproton.jfet.org (antiproton.jfet.org [209.141.47.85]) by mx1.riseup.net (Postfix) with ESMTP id 02A44C1217; Thu, 8 Oct 2015 10:52:50 -0700 (PDT) Authentication-Results: mx1.riseup.net; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from antiproton.jfet.org (localhost.localdomain [127.0.0.1]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98GGKrD02= 5641; Thu, 8 Oct 2015 12:16:22 -0400 Authentication-Results: antiproton.jfet.org; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98D0Cpb02= 2898 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128 v= erify=3DNOT) for <cypherpunks(a)cpunks.org>; Thu, 8 Oct 2015 09:00:13 -0400 Received: by qget97 with SMTP id t97so4690097qge.3 for <cypherpunks(a)cpunks.org>; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com= ; s=3D20120113; h=3Dmime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3D1O1OOVjsBLv9q1hSqCNzKTRiqHj1UiFhVVZ99fT9nUk=3D; b=3DbtcIUcqjMaDM/9XuseYtXTgf+M5nqN9SgrGIzgC+nnB/gcvmnrmPMPiWA5gtshS7sl 3JLqhoufjayaSDh5McuiPGm6jsNp0Bx4wcmypbn+0mqbgzZG5CeaTBEXjQyVV/sfYceC B+5Q+1WnQm9jU9rkPPCiRX3FrO7AHt00gNHg7HEol/gjz6Uud2DvBaFzGHJihmw3qJd3 GxSQXEkdEVHRxSkkaoln9ZPKcZ8wShMbiTSsmt0HM4VARiQRWERCkiL1YTMBjw6ZKyS1 uzHf23r/AWJrzxvwmbZDIqdXhl9cL1u7gxmWD22JBJ1UcNCWny3iCDPNu5sEI/by2Una r8DA=3D=3D MIME-Version: 1.0 X-Received: by 10.140.150.78 with SMTP id 75mr8520786qhw.11.1444309206533= ; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) Received: by 10.55.100.72 with HTTP; Thu, 8 Oct 2015 06:00:06 -0700 (PDT)=

1 0

None
by None 06 Jul '18

06 Jul '18

up.net X-Spam-Level:=20 X-Spam-Pyzor: Reported 0 times. X-Spam-Status: No, score=3D-2.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES= _00, CK_419SIZE,DKIM_SIGNED,ENV_FROM_DIFF0,FORWARD_RELAY, HEADER_FROM_DIFFERENT_DOMAINS,MAILPHISH4,ODD_PUNCTUATION2,RCVD_IN_DNSWL_= LOW, SPF_HELO_PASS,T_DKIM_INVALID shortcircuit=3Dno autolearn=3Ddisabled vers= ion=3D3.4.0 Delivered-To: rayzer(a)riseup.net Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure S= erver CA" (verified OK)) by spoonbill.riseup.net (Postfix) with ESMTPS id 25A8C238; Thu, 8 Oct 2015 17:52:52 +0000 (UTC) Received: from antiproton.jfet.org (antiproton.jfet.org [209.141.47.85]) by mx1.riseup.net (Postfix) with ESMTP id 02A44C1217; Thu, 8 Oct 2015 10:52:50 -0700 (PDT) Authentication-Results: mx1.riseup.net; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from antiproton.jfet.org (localhost.localdomain [127.0.0.1]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98GGKrD02= 5641; Thu, 8 Oct 2015 12:16:22 -0400 Authentication-Results: antiproton.jfet.org; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98D0Cpb02= 2898 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128 v= erify=3DNOT) for <cypherpunks(a)cpunks.org>; Thu, 8 Oct 2015 09:00:13 -0400 Received: by qget97 with SMTP id t97so4690097qge.3 for <cypherpunks(a)cpunks.org>; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com= ; s=3D20120113; h=3Dmime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3D1O1OOVjsBLv9q1hSqCNzKTRiqHj1UiFhVVZ99fT9nUk=3D; b=3DbtcIUcqjMaDM/9XuseYtXTgf+M5nqN9SgrGIzgC+nnB/gcvmnrmPMPiWA5gtshS7sl 3JLqhoufjayaSDh5McuiPGm6jsNp0Bx4wcmypbn+0mqbgzZG5CeaTBEXjQyVV/sfYceC B+5Q+1WnQm9jU9rkPPCiRX3FrO7AHt00gNHg7HEol/gjz6Uud2DvBaFzGHJihmw3qJd3 GxSQXEkdEVHRxSkkaoln9ZPKcZ8wShMbiTSsmt0HM4VARiQRWERCkiL1YTMBjw6ZKyS1 uzHf23r/AWJrzxvwmbZDIqdXhl9cL1u7gxmWD22JBJ1UcNCWny3iCDPNu5sEI/by2Una r8DA=3D=3D MIME-Version: 1.0 X-Received: by 10.140.150.78 with SMTP id 75mr8520786qhw.11.1444309206533= ; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) Received: by 10.55.100.72 with HTTP; Thu, 8 Oct 2015 06:00:06 -0700 (PDT)=

1 0

None
by None 06 Jul '18

06 Jul '18

up.net X-Spam-Level:=20 X-Spam-Pyzor: Reported 0 times. X-Spam-Status: No, score=3D-2.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES= _00, CK_419SIZE,DKIM_SIGNED,ENV_FROM_DIFF0,FORWARD_RELAY, HEADER_FROM_DIFFERENT_DOMAINS,MAILPHISH4,ODD_PUNCTUATION2,RCVD_IN_DNSWL_= LOW, SPF_HELO_PASS,T_DKIM_INVALID shortcircuit=3Dno autolearn=3Ddisabled vers= ion=3D3.4.0 Delivered-To: rayzer(a)riseup.net Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure S= erver CA" (verified OK)) by spoonbill.riseup.net (Postfix) with ESMTPS id 25A8C238; Thu, 8 Oct 2015 17:52:52 +0000 (UTC) Received: from antiproton.jfet.org (antiproton.jfet.org [209.141.47.85]) by mx1.riseup.net (Postfix) with ESMTP id 02A44C1217; Thu, 8 Oct 2015 10:52:50 -0700 (PDT) Authentication-Results: mx1.riseup.net; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from antiproton.jfet.org (localhost.localdomain [127.0.0.1]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98GGKrD02= 5641; Thu, 8 Oct 2015 12:16:22 -0400 Authentication-Results: antiproton.jfet.org; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98D0Cpb02= 2898 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128 v= erify=3DNOT) for <cypherpunks(a)cpunks.org>; Thu, 8 Oct 2015 09:00:13 -0400 Received: by qget97 with SMTP id t97so4690097qge.3 for <cypherpunks(a)cpunks.org>; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com= ; s=3D20120113; h=3Dmime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3D1O1OOVjsBLv9q1hSqCNzKTRiqHj1UiFhVVZ99fT9nUk=3D; b=3DbtcIUcqjMaDM/9XuseYtXTgf+M5nqN9SgrGIzgC+nnB/gcvmnrmPMPiWA5gtshS7sl 3JLqhoufjayaSDh5McuiPGm6jsNp0Bx4wcmypbn+0mqbgzZG5CeaTBEXjQyVV/sfYceC B+5Q+1WnQm9jU9rkPPCiRX3FrO7AHt00gNHg7HEol/gjz6Uud2DvBaFzGHJihmw3qJd3 GxSQXEkdEVHRxSkkaoln9ZPKcZ8wShMbiTSsmt0HM4VARiQRWERCkiL1YTMBjw6ZKyS1 uzHf23r/AWJrzxvwmbZDIqdXhl9cL1u7gxmWD22JBJ1UcNCWny3iCDPNu5sEI/by2Una r8DA=3D=3D MIME-Version: 1.0 X-Received: by 10.140.150.78 with SMTP id 75mr8520786qhw.11.1444309206533= ; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) Received: by 10.55.100.72 with HTTP; Thu, 8 Oct 2015 06:00:06 -0700 (PDT)=

1 0

None
by None 06 Jul '18

06 Jul '18

up.net X-Spam-Level:=20 X-Spam-Pyzor: Reported 0 times. X-Spam-Status: No, score=3D-2.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES= _00, CK_419SIZE,DKIM_SIGNED,ENV_FROM_DIFF0,FORWARD_RELAY, HEADER_FROM_DIFFERENT_DOMAINS,MAILPHISH4,ODD_PUNCTUATION2,RCVD_IN_DNSWL_= LOW, SPF_HELO_PASS,T_DKIM_INVALID shortcircuit=3Dno autolearn=3Ddisabled vers= ion=3D3.4.0 Delivered-To: rayzer(a)riseup.net Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure S= erver CA" (verified OK)) by spoonbill.riseup.net (Postfix) with ESMTPS id 25A8C238; Thu, 8 Oct 2015 17:52:52 +0000 (UTC) Received: from antiproton.jfet.org (antiproton.jfet.org [209.141.47.85]) by mx1.riseup.net (Postfix) with ESMTP id 02A44C1217; Thu, 8 Oct 2015 10:52:50 -0700 (PDT) Authentication-Results: mx1.riseup.net; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from antiproton.jfet.org (localhost.localdomain [127.0.0.1]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98GGKrD02= 5641; Thu, 8 Oct 2015 12:16:22 -0400 Authentication-Results: antiproton.jfet.org; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98D0Cpb02= 2898 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128 v= erify=3DNOT) for <cypherpunks(a)cpunks.org>; Thu, 8 Oct 2015 09:00:13 -0400 Received: by qget97 with SMTP id t97so4690097qge.3 for <cypherpunks(a)cpunks.org>; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com= ; s=3D20120113; h=3Dmime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3D1O1OOVjsBLv9q1hSqCNzKTRiqHj1UiFhVVZ99fT9nUk=3D; b=3DbtcIUcqjMaDM/9XuseYtXTgf+M5nqN9SgrGIzgC+nnB/gcvmnrmPMPiWA5gtshS7sl 3JLqhoufjayaSDh5McuiPGm6jsNp0Bx4wcmypbn+0mqbgzZG5CeaTBEXjQyVV/sfYceC B+5Q+1WnQm9jU9rkPPCiRX3FrO7AHt00gNHg7HEol/gjz6Uud2DvBaFzGHJihmw3qJd3 GxSQXEkdEVHRxSkkaoln9ZPKcZ8wShMbiTSsmt0HM4VARiQRWERCkiL1YTMBjw6ZKyS1 uzHf23r/AWJrzxvwmbZDIqdXhl9cL1u7gxmWD22JBJ1UcNCWny3iCDPNu5sEI/by2Una r8DA=3D=3D MIME-Version: 1.0 X-Received: by 10.140.150.78 with SMTP id 75mr8520786qhw.11.1444309206533= ; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) Received: by 10.55.100.72 with HTTP; Thu, 8 Oct 2015 06:00:06 -0700 (PDT)=

1 0

None
by None 06 Jul '18

06 Jul '18

up.net X-Spam-Level:=20 X-Spam-Pyzor: Reported 0 times. X-Spam-Status: No, score=3D-2.5 required=3D6.0 tests=3DAM_TRUNCATED,BAYES= _00, CK_419SIZE,DKIM_SIGNED,ENV_FROM_DIFF0,FORWARD_RELAY, HEADER_FROM_DIFFERENT_DOMAINS,MAILPHISH4,ODD_PUNCTUATION2,RCVD_IN_DNSWL_= LOW, SPF_HELO_PASS,T_DKIM_INVALID shortcircuit=3Dno autolearn=3Ddisabled vers= ion=3D3.4.0 Delivered-To: rayzer(a)riseup.net Received: from mx1.riseup.net (mx1-pn.riseup.net [10.0.1.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure S= erver CA" (verified OK)) by spoonbill.riseup.net (Postfix) with ESMTPS id 25A8C238; Thu, 8 Oct 2015 17:52:52 +0000 (UTC) Received: from antiproton.jfet.org (antiproton.jfet.org [209.141.47.85]) by mx1.riseup.net (Postfix) with ESMTP id 02A44C1217; Thu, 8 Oct 2015 10:52:50 -0700 (PDT) Authentication-Results: mx1.riseup.net; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from antiproton.jfet.org (localhost.localdomain [127.0.0.1]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98GGKrD02= 5641; Thu, 8 Oct 2015 12:16:22 -0400 Authentication-Results: antiproton.jfet.org; dkim=3Dfail reason=3D"verification failed; unprotected key" header.d=3Dgmail.com header.i=3D(a)gmail.com header.b=3DbtcIUcqj; dkim-adsp=3Dnone (unprotected policy); dkim-atps=3Dneutral Received: from mail-qg0-f65.google.com (mail-qg0-f65.google.com [209.85.192.65]) by antiproton.jfet.org (8.14.4/8.14.4/Debian-8) with ESMTP id t98D0Cpb02= 2898 (version=3DTLSv1/SSLv3 cipher=3DECDHE-RSA-AES128-GCM-SHA256 bits=3D128 v= erify=3DNOT) for <cypherpunks(a)cpunks.org>; Thu, 8 Oct 2015 09:00:13 -0400 Received: by qget97 with SMTP id t97so4690097qge.3 for <cypherpunks(a)cpunks.org>; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed; d=3Dgmail.com= ; s=3D20120113; h=3Dmime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=3D1O1OOVjsBLv9q1hSqCNzKTRiqHj1UiFhVVZ99fT9nUk=3D; b=3DbtcIUcqjMaDM/9XuseYtXTgf+M5nqN9SgrGIzgC+nnB/gcvmnrmPMPiWA5gtshS7sl 3JLqhoufjayaSDh5McuiPGm6jsNp0Bx4wcmypbn+0mqbgzZG5CeaTBEXjQyVV/sfYceC B+5Q+1WnQm9jU9rkPPCiRX3FrO7AHt00gNHg7HEol/gjz6Uud2DvBaFzGHJihmw3qJd3 GxSQXEkdEVHRxSkkaoln9ZPKcZ8wShMbiTSsmt0HM4VARiQRWERCkiL1YTMBjw6ZKyS1 uzHf23r/AWJrzxvwmbZDIqdXhl9cL1u7gxmWD22JBJ1UcNCWny3iCDPNu5sEI/by2Una r8DA=3D=3D MIME-Version: 1.0 X-Received: by 10.140.150.78 with SMTP id 75mr8520786qhw.11.1444309206533= ; Thu, 08 Oct 2015 06:00:06 -0700 (PDT) Received: by 10.55.100.72 with HTTP; Thu, 8 Oct 2015 06:00:06 -0700 (PDT)=

1 0