July 2018 - cypherpunks-legacy

[liberationtech] Global Occupy Map: Requesting Advice
by Chris 06 Jul '18

06 Jul '18

Hello Friends, My name is Chris, and I am a member of Occupy D.C. I am reaching out to this list at the suggestion of @LiberationTech with a few questions relating to mapping the Occupy movement. An Occupy-affiliated group, We All Occupy ( website<https://sites.google.com/site/wealloccupy/home>), has been painstakingly gathering data/links/advice/ and other resources on their site. I was able to geocode a listing of over 1300 Occupy locations globally, including their website URL, Facebook URL, and Twitter URL. Admittedly, the database still has many errors and is far from completion. I was then able to take this data and map each location with the appropriate URLs in a tooltip window using TileMill from MapBox: ( Global Occupy Map<http://a.tiles.mapbox.com/v3/upload.1sn5izz5.html#2.00/41.2/-13.3>) as well as a map with Socrata: ( OpenData Map <https://opendata.socrata.com/dataset/pointmap/bfrg-v5m8> ). I have three mapping-related inquiries: *1. Do you know of anyone/any organization who might be interested in hosting the open-source MapBox<http://developmentseed.org/about/open-source/> software on their servers for the Global Occupy Map? * Development Seed (MapBox/TileMill) has been generous in offering to host the map for one month. I imagine there to be many other liberating uses for this type of mapping technology, and I hope the Occupy map will inspire others to consider visualization as an advocacy tool. *2. How should I approach real-time data? * MapBox and Socrata are not, to my knowledge, very good at handling dynamic data, which is what the majority of what I imagine Occupy Data to be. (See Occupy Research here <http://occupyresearch.wikispaces.com/> for examples of previous visualizations, and I put together this stack of other Occupy maps for comparison: ( http://delicious.com/stacks/view/HruuI0 ). What I notice from the other maps is that the Ushahidi/CrowdMap maps are good for real-time but don't seem able to handle existing large datasets, and the tooltips/pop-up windows give limited information. The map itself is not very impressive. Data Visualization/maps should be beautiful, fun, perhaps even inspiring. I see some potential in using the Google Visualization API to generate dynamic maps, especially since data would be hosted in Google Docs already. However, I only recently (i.e., 2 months ago) started to script/develop. *3. Does anyone have experience in creating Google GeoMap Visualizations with a Google Docs spreadsheet as the source? * I apologize for the length of this email. I like to think it is because of all the links I included. Information is power! Sincerely, Chris _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/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

[CSL Colloq] Signaling Vulnerabilities in Law-Enforcement
by allison＠stanford.edu 06 Jul '18

06 Jul '18

Wiretap Systems * 4:15PM, Wed Mar 08, 2006 in Gates B01 Reply-To: ee380(a)shasta.stanford.edu Stanford EE Computer Systems Colloquium 4:15PM, Wednesday, Mar 08, 2006 HP Auditorium, Gates Computer Science Building B01 http://ee380.stanford.edu[1] Topic: Signaling Vulnerabilities in Law-Enforcement Wiretap Systems Speaker: Matt Blaze University of Pennsylvania About the talk: Telephone wiretap and dialed number recording systems are used by law enforcement and national security agencies to collect investigative intelligence and legal evidence. This talk will show how many of these systems are vulnerable to simple, unilateral countermeasures that allow wiretap targets to prevent their call audio from being recorded and/or cause false or inaccurate dialed digits and call activity to be logged. The countermeasures exploit the unprotected in-band signals passed between the telephone network and the collection system and are effective against many of the wiretapping technologies currently used by US law enforcement, including at least some ``CALEA'' systems. Possible remedies and workarounds will be proposed, and the broader implications of the security properties of these systems will be discussed. A recent paper, as well as audio examples of several wiretapping countermeasures, can be found at http://www.crypto.com/papers/wiretapping/ [2]. This is joint work with Micah Sherr, Eric Cronin, and Sandy Clark. About the speaker: Research: Prof Blaze's research focuses on the architecture and design of secure systems based on cryptographic techniques, analysis of secure systems against practical attack models, and on finding new cryptographic primitives and techniques. This work has led directly to several new cryptographic concepts, including: "Remotely-Keyed Encryption," which allows the use of inexpensive, low-bandwidth secure hardware to protect high-bandwidth communication and stored data, "Atomic Proxy Cryptography," which allows re-encryption by untrusted third parties, and "Master-Key Encryption," which provides a systematic way to design (and study) ciphers with built-in "back doors." Prof Blaze is especially interested in the use of encryption to protect insecure systems such as the Internet. He was a designer of swIPe, a predecessor of the now standard IPSEC protocol for protecting Internet traffic. Another project, CFS, investigated and demonstrated the feasibility of including encryption as file system service. Contact information: Matt Blaze University of Pennsylvania http://www.crypto.com[4] Embedded Links: [ 1 ] http://ee380.stanford.edu [ 2 ] http://www.crypto.com/papers/wiretapping/ [ 3 ] www.crypto.com [ 4 ] http://www.crypto.com ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

[IP] Stanford --Signaling Vulnerabilities in Law-Enforcement Wiretap
by David Farber 06 Jul '18

06 Jul '18

Systems * 4:15PM, Wed Mar 08, 2006 in Gates B01 X-Mailer: Apple Mail (2.746.2) Reply-To: dave(a)farber.net Begin forwarded message:

1 0

[tahoe-lafs-weekly-news] TWN #8
by Patrick R McDonald 06 Jul '18

06 Jul '18

======================================================= Tahoe-LAFS Weekly News, issue number 8, July 24, 2011 ======================================================= Welcome to the Tahoe-LAFS Weekly News (TWN). Tahoe-LAFS_ is a secure, distributed storage system. `View TWN on the web`_ *or* `subscribe to TWN`_. .. _Tahoe-LAFS: http://tahoe-lafs.org .. _View TWN on the web: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/TahoeLAFSWeeklyNews .. _subscribe to TWN: http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news Announcements and News ====================== Brian Warner announced_ the 1.9 plan. For a new feature to make into 1.9, it must have a ticket with a patch in the "Review-Needed" state by 24 July. The developers will review and land said patches over the following week, ending 31 July. Bug fixes will work exactly the same as new features except the patch and review needed deadline is 31 July and the developers' review ends 7 Aug. The beta should be cut on 8 Aug with 3 weeks of testing to follow. The final release is scheduled for 31 Aug. While MDMF will be the core of this release, Tahoe will not create them by default. Due to it being a compatibility impacting feature, the development team plans to have the feature in a release or two before enabling it by default. In the interests of allowing the developers to work towards 1.9, we are postponing the Interview with the Developers section until after the release. .. _announced: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006567.html Open Source Project of the Week =============================== The Open Source Project of the Week is `The Crypto Project`_. "The Crypto Project is an organization designed to assist and encourage anonymity and encryption research, development, and use. As part of this goal, we seek to revitalize the Cypherpunk movement and provide better software, security, and anonymity to individuals worldwide." The Crypto Project covers a variety of crypto projects including Tahoe-LAFS. .. _`The Crypto Project`: http://crypto.is >From the tahoe-dev Mailing List =============================== Linus Lussing started a discussion on Tahoe-LAFS and `SSHFS latency`_ issues. With 1.9 fast approaching, Zooko posted a `request for help`_ with updating the documentation. He already updated the FAQ_. In response to last week's question on the differences between Tahoe-LAFS and Freenet, Zooko provided a rather nice answer_. Zooko suggested_ dropping support for all versions of Python with the exception of 2.7 on Windows. Zooko recommended_ ticket 68_ to Andre Stenvall if Tahoe-LAFS still interested him for his master thesis work. Ticket 68_ works to implement distributed introduction, thereby eliminating the introducer as a single point of failure. Brandon Meskimen and Josh Wilcox discussed how to run a `Tahoe-LAFS introducer`_. Zooko and Samuel Neves discussed `hash based signatures`_ for Tahoe-LAFS. .. _`SSHFS latency`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006563.html .. _`request for help`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006562.html .. _FAQ: http://tahoe-lafs.org/trac/tahoe-lafs/wiki/FAQ .. _answer: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006560.html .. _suggested: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006558.html .. _recommended: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006556.html .. _68: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# .. _`Tahoe-LAFS introducer`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006555.html .. _`hash based signatures`: http://tahoe-lafs.org/pipermail/tahoe-dev/2011-July/006554.html Patch Needing Review of the Week ================================ The Patch Needing Review of the Week is 393_. This patch covers MDMF, a key feature in 1.9. You may recall MDMF from our `interview with Kevan`_. When the review is completed, we are one step closer to 1.9 .. _393: http://tahoe-lafs.org/trac/tahoe-lafs/ticket/393 .. _`interview with Kevan`: http://tahoe-lafs.org/~zooko/TWN2.html ---- *The Tahoe-LAFS Weekly News is published once a week by The Tahoe-LAFS Software Foundation, President and Treasurer: Peter Secor. Scribes: Patrick "marlowe" McDonald, Zooko Wilcox-O'Hearn, Editor: Zooko.* `View TWN on the web`_ *or* `subscribe to TWN`_ *. Send your news stories to* marlowe(a)antagonism.org_ *b submission deadline: Friday night.* .. _marlowe(a)antagonism.org: mailto:marlowe@antagonism.org _______________________________________________ tahoe-lafs-weekly-news mailing list tahoe-lafs-weekly-news(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-lafs-weekly-news ----- 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

[liberationtech] Global Occupy Map: Requesting Advice
by Chris 06 Jul '18

06 Jul '18

Hello Friends, My name is Chris, and I am a member of Occupy D.C. I am reaching out to this list at the suggestion of @LiberationTech with a few questions relating to mapping the Occupy movement. An Occupy-affiliated group, We All Occupy ( website<https://sites.google.com/site/wealloccupy/home>), has been painstakingly gathering data/links/advice/ and other resources on their site. I was able to geocode a listing of over 1300 Occupy locations globally, including their website URL, Facebook URL, and Twitter URL. Admittedly, the database still has many errors and is far from completion. I was then able to take this data and map each location with the appropriate URLs in a tooltip window using TileMill from MapBox: ( Global Occupy Map<http://a.tiles.mapbox.com/v3/upload.1sn5izz5.html#2.00/41.2/-13.3>) as well as a map with Socrata: ( OpenData Map <https://opendata.socrata.com/dataset/pointmap/bfrg-v5m8> ). I have three mapping-related inquiries: *1. Do you know of anyone/any organization who might be interested in hosting the open-source MapBox<http://developmentseed.org/about/open-source/> software on their servers for the Global Occupy Map? * Development Seed (MapBox/TileMill) has been generous in offering to host the map for one month. I imagine there to be many other liberating uses for this type of mapping technology, and I hope the Occupy map will inspire others to consider visualization as an advocacy tool. *2. How should I approach real-time data? * MapBox and Socrata are not, to my knowledge, very good at handling dynamic data, which is what the majority of what I imagine Occupy Data to be. (See Occupy Research here <http://occupyresearch.wikispaces.com/> for examples of previous visualizations, and I put together this stack of other Occupy maps for comparison: ( http://delicious.com/stacks/view/HruuI0 ). What I notice from the other maps is that the Ushahidi/CrowdMap maps are good for real-time but don't seem able to handle existing large datasets, and the tooltips/pop-up windows give limited information. The map itself is not very impressive. Data Visualization/maps should be beautiful, fun, perhaps even inspiring. I see some potential in using the Google Visualization API to generate dynamic maps, especially since data would be hosted in Google Docs already. However, I only recently (i.e., 2 months ago) started to script/develop. *3. Does anyone have experience in creating Google GeoMap Visualizations with a Google Docs spreadsheet as the source? * I apologize for the length of this email. I like to think it is because of all the links I included. Information is power! Sincerely, Chris _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/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

[cryptography] NSA Releases 136 Cryptologs 1974-1997
by John Young 06 Jul '18

06 Jul '18

Most of the Cryptologs were formerly classified Top Secret. NSA calls it a "monumental release." Non-searchable image files at NSA: http://www.nsa.gov/public_info/declass/cryptologs.shtml The full collection in a Zipped file: http://www.governmentattic.org/7docs/NSA-Cryptolog_1997-1974.pdf (240MB) We OCRed the collection to raw text, no formatting, no proofreading but fully searchable: http://cryptome.org/2013/03/nsa-cryptologs-text.zip (4.4MB) _______________________________________________ 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

A Few Random Thoughts...
by Michael 06 Jul '18

06 Jul '18

Hi all, As one of those lucky souls with access to almost limitless bandwidth and the skills (or stupidity) to use it, I suppose an apology is in order: I'm sorry- after reviewing what *could* be the consequences, I have to whimp out based on professional risk factors... I can't run an exit node. So I have to leave it to other folks who have a different situation to do the heavy lifting. What I *am* doing is deploying a couple of heavy iron closed relays on OC3 or better bandwidth. The first is now deployed after a lot of up and down testing, and I'll get to the second in due time. I've been watching Tor for a long time and just recently decided to get involved. The Iran situation cemented that decision. Anyhow, here are some random thoughts: On the "Who uses Tor?" section of the website, I see no mention of IT people. I've used the Tor network for many practical uses as an IT Director. These range from bypassing my own firewall to test incoming connections, to helping my legal department do research on a pending lawsuit without the opposition *knowing* we even looked at their website. Having a random and easily accessible IP to initiate connections from is a priceless testing tool. Especially when dealing with niggling routing problems. On one occasion my ISP was having routing/DNS problems, and Tor was able to find an entrance node and allow me to work even though I couldn't get to my remote servers directly. This saved my client a lot of downtime, and might have saved me the account. Also, my employer's R&D department sometimes needs to look at things they don't want anyone to know they looked at (All quite legal mind you). Quite frankly Tor is an undervalued IT tool and it's capabilities should be trumpeted loudly on the web page. You might also find IT guys like me throwing up some relays in exchange. After all- who has the bandwidth anyway? And before anyone accuses me of it, I'm not nearly stupid enough to do a port scan over Tor. Phew. One of the issues I ran into when looking into running an exit relay had to do with not only the legalities, but identifying a server vendor that was offshore from my home country and friendly to a Tor exit. In order for me to run an exit node, I have to be completely shielded. As it stands now, I can probably run an exit for instant messaging- and that's it. However, if Tor itself had a relationship with someone who rents hardware, perhaps a partnership, Tor could get the exit nodes it needs, and the server vendor could get lots of cash. From my standpoint, it doesn't matter whether I rent or colocate my hardware. So if Tor as an organization had a partnership with a few server rental whores (in multiple countries), it would simplify getting more exits. I need servers, Tor runs with little impact on my server, I could care less where my remote hardware is provisioned from. Bingo- more exits. I read back about 6 months in the or-talk list and there were a couple of suggestions inferring that *everyone* should be forced to be an exit node. I think this is a very bad idea, and hurts the security of the person trying to remain anonymous by causing an identifiable change in bandwidth usage that could infer Tor usage (Information leakage). Simply speaking, on a default Windows/Vidalia installation, outgoing Tor traffic usually looks like https traffic, but on a forced exit, now Tor is identified by relatively matched traffic on port 443 both in and out of the client's connection (Unless it's entrance node is a *nix variant). This could mean death (literal) for a political dissident who is now identified as having an in/out matching traffic pattern assuming his entrance node is on Windows. It is more likely, that a country monitoring it's citizens would miss simple https traffic. But even myself as a lowly IT director, would have alarm bells going off if https was initiating in two directions from the same machine. Alternative ports can also set off alarm bells. But given the nature of Onion Routing, two way traffic needs to be avoided in the most sensitive sensitive situations. Forcing exit nodes is a bad idea for users. It will also drive away anyone who cannot provide an exit node.... that's chasing away bandwidth as non exit relays run for the hills. Long post. Too much coffee and too much time staring at routing tables. Michael ----- 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

A Few Random Thoughts...
by Eugen Leitl 06 Jul '18

06 Jul '18

----- Forwarded message from Michael <cozzi(a)cozziconsulting.com> -----

1 0

What happened to the Cryptography list...?
by ghicks＠cadence.com 06 Jul '18

06 Jul '18

Kind sir: As the subject says... All of a sudden mail just stopped. Figuring that I had, somehow, become unsubscribed from the list, I tried to re-subscribe. This resulted in an "Unknown list" message from majordomo@wasabisystems... Any ideas? could assist please? I know that you are not the list owner, but you, at one time, seemed to be active on the list. Regards, Gregory Hicks --- end forwarded text

1 0

A Few Random Thoughts...
by Michael 06 Jul '18

06 Jul '18

Hi all, As one of those lucky souls with access to almost limitless bandwidth and the skills (or stupidity) to use it, I suppose an apology is in order: I'm sorry- after reviewing what *could* be the consequences, I have to whimp out based on professional risk factors... I can't run an exit node. So I have to leave it to other folks who have a different situation to do the heavy lifting. What I *am* doing is deploying a couple of heavy iron closed relays on OC3 or better bandwidth. The first is now deployed after a lot of up and down testing, and I'll get to the second in due time. I've been watching Tor for a long time and just recently decided to get involved. The Iran situation cemented that decision. Anyhow, here are some random thoughts: On the "Who uses Tor?" section of the website, I see no mention of IT people. I've used the Tor network for many practical uses as an IT Director. These range from bypassing my own firewall to test incoming connections, to helping my legal department do research on a pending lawsuit without the opposition *knowing* we even looked at their website. Having a random and easily accessible IP to initiate connections from is a priceless testing tool. Especially when dealing with niggling routing problems. On one occasion my ISP was having routing/DNS problems, and Tor was able to find an entrance node and allow me to work even though I couldn't get to my remote servers directly. This saved my client a lot of downtime, and might have saved me the account. Also, my employer's R&D department sometimes needs to look at things they don't want anyone to know they looked at (All quite legal mind you). Quite frankly Tor is an undervalued IT tool and it's capabilities should be trumpeted loudly on the web page. You might also find IT guys like me throwing up some relays in exchange. After all- who has the bandwidth anyway? And before anyone accuses me of it, I'm not nearly stupid enough to do a port scan over Tor. Phew. One of the issues I ran into when looking into running an exit relay had to do with not only the legalities, but identifying a server vendor that was offshore from my home country and friendly to a Tor exit. In order for me to run an exit node, I have to be completely shielded. As it stands now, I can probably run an exit for instant messaging- and that's it. However, if Tor itself had a relationship with someone who rents hardware, perhaps a partnership, Tor could get the exit nodes it needs, and the server vendor could get lots of cash. From my standpoint, it doesn't matter whether I rent or colocate my hardware. So if Tor as an organization had a partnership with a few server rental whores (in multiple countries), it would simplify getting more exits. I need servers, Tor runs with little impact on my server, I could care less where my remote hardware is provisioned from. Bingo- more exits. I read back about 6 months in the or-talk list and there were a couple of suggestions inferring that *everyone* should be forced to be an exit node. I think this is a very bad idea, and hurts the security of the person trying to remain anonymous by causing an identifiable change in bandwidth usage that could infer Tor usage (Information leakage). Simply speaking, on a default Windows/Vidalia installation, outgoing Tor traffic usually looks like https traffic, but on a forced exit, now Tor is identified by relatively matched traffic on port 443 both in and out of the client's connection (Unless it's entrance node is a *nix variant). This could mean death (literal) for a political dissident who is now identified as having an in/out matching traffic pattern assuming his entrance node is on Windows. It is more likely, that a country monitoring it's citizens would miss simple https traffic. But even myself as a lowly IT director, would have alarm bells going off if https was initiating in two directions from the same machine. Alternative ports can also set off alarm bells. But given the nature of Onion Routing, two way traffic needs to be avoided in the most sensitive sensitive situations. Forcing exit nodes is a bad idea for users. It will also drive away anyone who cannot provide an exit node.... that's chasing away bandwidth as non exit relays run for the hills. Long post. Too much coffee and too much time staring at routing tables. Michael ----- 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