July 2018 - cypherpunks-legacy

[IP] more on more on E-mail intercept ruling - good grief!!
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[tahoe-announce] ANN: Tahoe-LAFS 1.9 Released!
by Brian Warner 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.9.0 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.9.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.8.3, which was released September 13, 2011. v1.9.0 offers a new mutable-file format (more efficient for large files), a file-blacklisting feature, and a new "drop-upload" feature. See the NEWS file [3] and known_issues.rst [4] file for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [5]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the fifteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.rst" [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.rst" [6]. HACKING AND COMMUNITY Please join us on the mailing list [7]. Patches are gratefully accepted -- the RoadMap page [8] shows the next improvements that we plan to make and CREDITS [9] lists the names of people who've contributed to the project. The Dev page [10] contains resources for hackers. SPONSORSHIP Atlas Networks has contributed several hosted servers for performance testing. Thank you to Atlas Networks [11] for their generous and public-spirited support. And a special thanks to Least Authority Enterprises [12], which employs several Tahoe-LAFS developers, for their continued support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [13]. ACKNOWLEDGEMENTS This is the ninth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. Brian Warner on behalf of the Tahoe-LAFS team October 31, 2011 San Francisco, California, USA [1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst?rev=5356 [2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst [3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects [4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL [5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst [6] https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst [7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap [9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5356 [10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev [11] http://atlasnetworks.us/ [12] http://leastauthority.com/ [13] https://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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: [IP] more on E-mail intercept ruling - good grief!!
by Peter Swire 06 Jul '18

06 Jul '18

Dave: On VOIP interception, there is a statutory and a constitutional issue. The statutory issue is whether VOIP is a "wire" communication (like a phone call) or an "electronic" communication (like an e-mail or web communication). The Councilman court said that "wire" communications are considered "intercepted" even if they are in temporary storage. The key holding of the case was that "electronic" communications are not "intercepted" if the wiretap takes place while the communication is in temporary storage. "Wire communication" is defined as "any aural transfer made in whole or in part through the use of facilities for the transmission of communications by the aid of wire, cable or other like connection between the point of origin and the point of reception." I do not know whether a court has ruled on whether VOIP counts as a "wire communication." Quick research just now suggests we don't have a case on that yet. I can see arguments either way, based in part on whether a packet-switched communication counts as "aural." Under Councilman, if VOIP is an "electronic communication", then the provider therefore could intercept the VOIP calls for the provider's own use without it counting as an "interception." Providers already can intercept communications with user consent or to protect the system, but this would be blanket permission to intercept communications. The constitutional question is whether users have a "reasonable expectation of privacy" in VOIP phone calls. Since the 1960's, the Supreme Court has found a 4th Amendment protection for voice phone calls. Meanwhile, it has found no constitutional protection for stored records. In an article coming out shortly from the Michigan Law Review, I show why VOIP calls quite possibly will be found NOT to have constitutional protection under the 4th Amendment. It would then be up to Congress to fix this, or else have the Supreme Court change its doctrine to provide more protections against future wiretaps. Article at http://papers.ssrn.com/sol3/papers.cfm?abstract_id=490623 . Peter Prof. Peter P. Swire Moritz College of Law, Ohio State University John Glenn Scholar in Public Policy Research (240) 994-4142, www.peterswire.net -----Original Message----- From: owner-ip(a)v2.listbox.com [mailto:owner-ip@v2.listbox.com] On Behalf Of David Farber Sent: Thursday, July 01, 2004 12:12 PM To: Ip Subject: [IP] more on E-mail intercept ruling - good grief!! Begin forwarded message:

1 0

Re: [IP] E-mail intercept ruling - good grief!!
by Ed Belove 06 Jul '18

06 Jul '18

But Councilman argued that no violation of the Wiretap Act had occurred because the e-mails were copied while in "electronic storage" -- the messages were in the process of being routed through a network of servers to recipients. A scary thought: does this mean that VOIP packets can be copied from routers (by ISPs or anyone else) while they are "stored"? ------------------------------------- You are subscribed as peter(a)peterswire.net To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ------------------------------------- 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> ______________________________________________________________ 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

[IP] more on more on E-mail intercept ruling - good grief!!
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

[tahoe-announce] ANN: Tahoe-LAFS 1.9 Released!
by Brian Warner 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.9.0 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.9.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/quickstart.rst Tahoe-LAFS is the first distributed storage system to offer "provider-independent security" b meaning that not even the operators of your storage servers can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: https://tahoe-lafs.org/source/tahoe-lafs/trunk/docs/about.rst The previous stable release of Tahoe-LAFS was v1.8.3, which was released September 13, 2011. v1.9.0 offers a new mutable-file format (more efficient for large files), a file-blacklisting feature, and a new "drop-upload" feature. See the NEWS file [3] and known_issues.rst [4] file for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers fail or are taken over by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems, including Windows, JavaScript, iPhone, Android, Hadoop, Flume, Django, Puppet, bzr, mercurial, perforce, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [5]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or cloud storage. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all important issues that we are currently aware of please see the known_issues.rst file [2].) COMPATIBILITY This release is compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the fifteenth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the foreseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with this series. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [4] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to delay for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.rst" [5] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.rst" [6]. HACKING AND COMMUNITY Please join us on the mailing list [7]. Patches are gratefully accepted -- the RoadMap page [8] shows the next improvements that we plan to make and CREDITS [9] lists the names of people who've contributed to the project. The Dev page [10] contains resources for hackers. SPONSORSHIP Atlas Networks has contributed several hosted servers for performance testing. Thank you to Atlas Networks [11] for their generous and public-spirited support. And a special thanks to Least Authority Enterprises [12], which employs several Tahoe-LAFS developers, for their continued support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that we feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [13]. ACKNOWLEDGEMENTS This is the ninth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. Brian Warner on behalf of the Tahoe-LAFS team October 31, 2011 San Francisco, California, USA [1] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/NEWS.rst?rev=5356 [2] https://tahoe-lafs.org/trac/tahoe-lafs/browser/docs/known_issues.rst [3] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/RelatedProjects [4] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.GPL [5] https://tahoe-lafs.org/trac/tahoe-lafs/browser/COPYING.TGPPL.rst [6] https://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.rst [7] https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [8] https://tahoe-lafs.org/trac/tahoe-lafs/roadmap [9] https://tahoe-lafs.org/trac/tahoe-lafs/browser/trunk/CREDITS?rev=5356 [10] https://tahoe-lafs.org/trac/tahoe-lafs/wiki/Dev [11] http://atlasnetworks.us/ [12] http://leastauthority.com/ [13] https://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)tahoe-lafs.org http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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: [ZS] ZS reboot seed
by Bryce Lynch 06 Jul '18

06 Jul '18

On Thu, Sep 20, 2012 at 8:19 AM, Dirk Bruere <dirk.bruere(a)gmail.com> wrote: > Darknet server with encrypted list - doubly hidden and with only a > handful of people who know the passwords and locations. In fact, apart How about lots of them - one per member? Barring the transition of an x-risk into an x-occurrance, only one copy would have to survive. > from one person, the passwords and location could be kept seperate ie > only one person knows both. And the others do not all know each other. > A "buddy system" There are distributed, federated wikis out there. There are federated, distributed chat systems out there. There are distributed file stores out there. There are federated, distributed socnets out there. There is no reason that we can't go mycelial and automagically distribute copies of every/thing/ every/where/. -- The Doctor [412/724/301/703] [ZS] https://drwho.virtadpt.net/ "I am everywhere." -- -- Zero State mailing list: http://groups.google.com/group/DoctrineZero ----- 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

privacy in public places
by Perry E. Metzger 06 Jul '18

06 Jul '18

There has been a lot of talk on the list recently about the privacy issues associated with various toll and fare collecting systems, but others have been pointing out, correctly I think, that this matters less and less because of other technological developments. New York City recently announced plans to use license plate OCR to produce and keep records of every car entering and leaving the city and to keep those records for years. Very little attention was paid to this, but I think it is the mark of things to come. Although the huge infestations of video cameras in our cities have had almost no impact on crime, once they are combined with sufficiently potent image recognition software, it will become possible to track people's movements and keep records of those movements essentially forever. It also seems to me that almost anything that can be done will in fact happen in the current "opposing the wish lists of the police is the same as being in favor of terrorism" environment. Given this, I think the time for focusing on the privacy implications of payment transponders and fare cars is over. Not carrying a cell phone will not help you avoid tracking when your environment is saturated with cameras. Digital cash toll collection systems will not avoid records being kept of your car's movements when cameras are reading and recording license plates anyway. Unfortunately, I don't see anything technological that people can reasonably do here to provide more privacy, at least short of everyone going everywhere on foot while wearing a burqa and periodically attempting to confuse the cameras. The solutions, if any exist at all, appear to be non-technical. Perry -- Perry E. Metzger perry(a)piermont.com --------------------------------------------------------------------- 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

Review of new book on the NSA
by Steven Bellovin 06 Jul '18

06 Jul '18

There's a new book on the NSA, based largely on documents received via Freedom of Information Act requests. Bamford's review is at http://www.nybooks.com/articles/23231 . --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- 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

privacy in public places
by Perry E. Metzger 06 Jul '18

06 Jul '18

There has been a lot of talk on the list recently about the privacy issues associated with various toll and fare collecting systems, but others have been pointing out, correctly I think, that this matters less and less because of other technological developments. New York City recently announced plans to use license plate OCR to produce and keep records of every car entering and leaving the city and to keep those records for years. Very little attention was paid to this, but I think it is the mark of things to come. Although the huge infestations of video cameras in our cities have had almost no impact on crime, once they are combined with sufficiently potent image recognition software, it will become possible to track people's movements and keep records of those movements essentially forever. It also seems to me that almost anything that can be done will in fact happen in the current "opposing the wish lists of the police is the same as being in favor of terrorism" environment. Given this, I think the time for focusing on the privacy implications of payment transponders and fare cars is over. Not carrying a cell phone will not help you avoid tracking when your environment is saturated with cameras. Digital cash toll collection systems will not avoid records being kept of your car's movements when cameras are reading and recording license plates anyway. Unfortunately, I don't see anything technological that people can reasonably do here to provide more privacy, at least short of everyone going everywhere on foot while wearing a burqa and periodically attempting to confuse the cameras. The solutions, if any exist at all, appear to be non-technical. Perry -- Perry E. Metzger perry(a)piermont.com --------------------------------------------------------------------- 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