July 2018 - cypherpunks-legacy

[Politech] New Jersey, California officials like the Real ID Act [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

So I spent part of this week at the RSA conference in San Francisco, where I stopped by a panel that seemed to be created by and intended for state DMV officials. The topic was the Real ID Act, and everyone seemed to either like it a lot or be entirely in love with the scheme. All were former or current government officials, and not one said it was a bad idea. In fact, California and (especially) New Jersey loved it: http://news.com.com/2100-1028_3-6157813.html One idea they had was for the feds to mandate biometrics (fingerprint, retinal scan, DNA sample) on these federalized ID cards. Right now DHS can but isn't required to do so; we're still waiting for the regulations to be made public. Another idea came from Paula Arcioni, the chief information security officer for New Jersey's Office of Information Technology, and a member of the National Electronic Commerce Coordinating Council: http://www.ec3.org/About/AboutBoard.htm Clearly electronic commerce could never happen unless it were properly "coordinated" by some state governments. Anyway, Arcioni not only applauded the law but said it would be made much better if it was turned into a microprocessor-enabled smartcard that both state governments and corporations could use for online authentication. Compare this to what Maine did a few weeks ago: http://www.politechbot.com/2007/01/25/maine-becomes-first/ Guess these states either haven't gotten the message yet, or perhaps these midlevel bureaucrats are simply so caught up in their own fiefdoms that they ignore what the public actually wants. -Declan _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.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 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

[HacDC:Byzantium] A wild release candidate appears!
by The Doctor 06 Jul '18

06 Jul '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In preparation for a demo next week we've started working on a new round of release candidate (RC) .iso images. We've added some of the more stable network apps back into Byzantium Linux (namely, Etherpad-Lite and ngircd/QwebIRC), and we've added the OLSR network visualization utility, which shows the topology of the mesh as the node in question knows it as well as network dynamics. What we don't have yet is the service directory (which will be a static HTML file with links to all of the services). For the sake of brevity we also have not put back the Avahi stuff. However, this might change depending on how to AWMH (Aaron Swartz Memorial Hackathon) goes tomorrow. We'll let everyone know. The latest and greatest can be downloaded from here: http://project-byzantium.org/downloads/v0.3a/byzantium-v0.3a-RC-20130201-21… SHA-1 hash: 3da4db0ad345a475c20d88390e1c8fc57fe4c033 If anybody has time, download this .iso and give it a shot! Let us know what works, what doesn't, and what could use cleaned up and we'll get to it tomorrow! - -- The Doctor [412/724/301/703] [ZS|Media] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ fear == funding -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlEMjYIACgkQO9j/K4B7F8FKrACePUvyB7DVekbH04eAlCMLCuZ3 leoAn3aQuT5y/+7kv9S3h4Z9OB/dRTa6 =rgF4 -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "Project Byzantium (Emergency Mesh Networking)" group. To post to this group, send email to Byzantium(a)hacdc.org. To unsubscribe from this group, send email to Byzantium+unsubscribe(a)hacdc.org. For more options, visit this group at http://groups.google.com/a/hacdc.org/group/Byzantium/?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: how bad is IPETEE?
by zooko 06 Jul '18

06 Jul '18

On Jul 15, 2008, at 16:33 PM, Leichter, Jerry wrote: >The goal is >to use some form of opportunistic encryption to make as much >Internet traffic as possible encrypted as quickly as possible - >which puts all kinds of constraints on a solution, Oh, then they should learn about Adam Langley's Obfuscated TCP: http://code.google.com/p/obstcp/ One of the design constraints for Obfuscated TCP was that an Obfuscated TCP connection is required to take zero more round trips to set up and use than a normal TCP connection. Way to go, Adam! Regards, Zooko ----- 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: how bad is IPETEE?
by zooko 06 Jul '18

06 Jul '18

On Jul 15, 2008, at 16:33 PM, Leichter, Jerry wrote: >The goal is >to use some form of opportunistic encryption to make as much >Internet traffic as possible encrypted as quickly as possible - >which puts all kinds of constraints on a solution, Oh, then they should learn about Adam Langley's Obfuscated TCP: http://code.google.com/p/obstcp/ One of the design constraints for Obfuscated TCP was that an Obfuscated TCP connection is required to take zero more round trips to set up and use than a normal TCP connection. Way to go, Adam! Regards, Zooko ----- 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

[tahoe-announce] ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0c4
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0c4 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.0c4 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning 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: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The current stable release of Tahoe-LAFS is v1.7.1, which was released July 18, 2010 [1]. v1.8.0 offers greatly improved performance and fault-tolerance of downloads and improved Windows support. See the NEWS file [2] for details. v1.8.0c4 is the release candidate for v1.8.0. v1.8.0c4 fixed a unit test failure and added some documentation and build system improvements. v1.8.0c3 fixed performance regressions for some server layouts. v.1.80c2 corrected some minor regressions in download status pages. v1.8.0c1 corrected regressions in compatibility with other versions, and in downloads using the Range header, that were introduced in v1.8.0N2. If no further regressions or critical bugs are discovered, we will release v1.8.0 final on September 18, 2010. 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 [3]. 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.txt file [4].) 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 eleventh release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable 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" [5] 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.html" [6] 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, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Google, Inc. sponsored Tahoe-LAFS development as part of the Google Summer of Code 2010. They awarded four sponsorships to students from around the world to hack on Tahoe-LAFS that summer. Thank you to Allmydata and Google for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that 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" [12]. ACKNOWLEDGEMENTS This is the fifth 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. David-Sarah Hopwood and Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team September 11, 2010 Rainhill, Merseyside, UK and Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4579 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4692 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4591 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://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

[tahoe-announce] ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0c4
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

ANNOUNCING Tahoe, the Least-Authority File System, v1.8.0c4 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.8.0c4 of Tahoe-LAFS, an extremely reliable distributed storage system. Get it here: http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning 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: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html The current stable release of Tahoe-LAFS is v1.7.1, which was released July 18, 2010 [1]. v1.8.0 offers greatly improved performance and fault-tolerance of downloads and improved Windows support. See the NEWS file [2] for details. v1.8.0c4 is the release candidate for v1.8.0. v1.8.0c4 fixed a unit test failure and added some documentation and build system improvements. v1.8.0c3 fixed performance regressions for some server layouts. v.1.80c2 corrected some minor regressions in download status pages. v1.8.0c1 corrected regressions in compatibility with other versions, and in downloads using the Range header, that were introduced in v1.8.0N2. If no further regressions or critical bugs are discovered, we will release v1.8.0 final on September 18, 2010. 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 [3]. 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.txt file [4].) 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 eleventh release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable 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" [5] 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.html" [6] 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, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Google, Inc. sponsored Tahoe-LAFS development as part of the Google Summer of Code 2010. They awarded four sponsorships to students from around the world to hack on Tahoe-LAFS that summer. Thank you to Allmydata and Google for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that 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" [12]. ACKNOWLEDGEMENTS This is the fifth 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. David-Sarah Hopwood and Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team September 11, 2010 Rainhill, Merseyside, UK and Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4579 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4692 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4591 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://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: Network security on multiple levels (was Re: NYT covers China cyberthreat)
by Warren Bailey 06 Jul '18

06 Jul '18

I did not approach the inline encryption units on purpose. Obviously anything that leaves .mil land not riding something blessed by DISA is going to have something like a KG on both ends. Generally Satellite systems use TRANSEC, though in our line of work it's an extremely expensive add-on to an otherwise decent security implementation. I'm not saying it can NEVER be owned, I'm just saying that 90% of the l33t hax0rs who are going to look to own something are doing so because it is somehow exposed to public infrastructure. If I were to put up an SCPC (single channel per carrier, synonymous to point to point circuits) circuit between point A and B, the persons looking to intercept my traffic would need to know quite a bit of information about my signals.. Origination Point, Destination Point, Modulation, Symbol Rates, Center Frequencies, PN codes, TRANSEC keys, IP lay out, etc. You won't hear me talk about how something is absolutely and completely secure, but you will hear me preach from the rooftops the application of technology that many people believe is outdated and abandoned. There is a reason media providers and MSO's still use Satellite to downlink video signals. The military is still heavily invested in this type of technology because you are able to completely bypass traditionally used infrastructure, and Utility companies are jumping on the band wagon as well. I know of several SCADA (massive power companies) networks that ride satellite completely for this reason. You can justify the cost and latency with the security of owning a network that is completely removed from the usual infrastructure. On 2/20/13 10:05 AM, "Jamie Bowden" <jamie(a)photon.com> wrote: >> From: Warren Bailey [mailto:wbailey@satelliteintelligencegroup.com] > > >> If you are doing DS0 splitting on the DACS, you'll see that on the >> other >> end (it's not like channelized CAS ds1's or PRI's are difficult to look >> at >> now) assuming you have access to that. If the DACS is an issue, buy the >> DACS and lock it up. I was on a .mil project that used old school >> Coastcom >> DI III Mux with RLB cards and FXO/FXS cards, that DACS carried some >> pretty >> top notch traffic and the microwave network (licensed .gov band) >> brought >> it right back to the base that project was owned by. Security is >> expensive, because you cannot leverage a service provider model >> effectively around it. You can explain the billion dollars you spent on >> your global network of CRS-1's, but CRS-1's for a single application >> usually are difficult to swallow. I'm not saying that it isn't done >> EVER, >> I'm just saying there are ways to avoid your 1998 red hat box from >> rpc.statd exploitation - unplug aforementioned boxen from inter webs. > >Our connections to various .mil and others are private ds1's with full on >end to end crypto over them. You can potentially kill our connections, >but you're not snooping them or injecting traffic into them. > >Jamie > ----- 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 Robert Guerra 06 Jul '18

06 Jul '18

> I think that it should be written into Canada's constitution that ANY > information about any Candadian citizen belongs to that citizen. I'm so pissed off about this idea... You mean like I'd be sued for using your name in this email? What if my name was "Robert" - do we "share" the loot when we sue the cypherpunks node owner for using our names? Yuck. Ownership is irrelevant to information; bits aren't naturally scarce. [What if I'm using the number "32", which just happens to be your age? Or "174" which happens to be your weight? What does "any information about any citizen" mean?] Mark

1 0

None
by Robert Guerra 06 Jul '18

06 Jul '18

> I think that it should be written into Canada's constitution that ANY > information about any Candadian citizen belongs to that citizen. I'm so pissed off about this idea... You mean like I'd be sued for using your name in this email? What if my name was "Robert" - do we "share" the loot when we sue the cypherpunks node owner for using our names? Yuck. Ownership is irrelevant to information; bits aren't naturally scarce. [What if I'm using the number "32", which just happens to be your age? Or "174" which happens to be your weight? What does "any information about any citizen" mean?] Mark

1 0

None
by Robert Guerra 06 Jul '18

06 Jul '18

> I think that it should be written into Canada's constitution that ANY > information about any Candadian citizen belongs to that citizen. I'm so pissed off about this idea... You mean like I'd be sued for using your name in this email? What if my name was "Robert" - do we "share" the loot when we sue the cypherpunks node owner for using our names? Yuck. Ownership is irrelevant to information; bits aren't naturally scarce. [What if I'm using the number "32", which just happens to be your age? Or "174" which happens to be your weight? What does "any information about any citizen" mean?] Mark

1 0