July 2018 - cypherpunks-legacy

[IP] more on CA State bill could cripple P2P
by David Farber 06 Jul '18

06 Jul '18

------ Forwarded Message From: Mike O'Dell <mo(a)ccr.org> Date: Wed, 19 Jan 2005 13:58:18 -0500 To: <dave(a)farber.net> Subject: Re: [IP] CA State bill could cripple P2P actually, taken at face value, this outlaws all network protocol stacks I know about, even terminal emulators with things like x-modem and even file redirection. it's patently bogus, but it could do an immense amount of mischief done before it gets undone (assuming it ever gets done). What i'd like to see is a bill punishing legislators for introducing unconstitutional bills. if a bill is declared unconstitutional, the sponsors of the bill would do prison time for an assault on the public freedom. -mo ------ End of Forwarded Message ------------------------------------- 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

<nettime> New Book: Internet and Surveillance: The Challenges of Web 2.0 and Social Media
by Christian Fuchs 06 Jul '18

06 Jul '18

Fuchs, Christian, Kees Boersma, Anders Albrechtslund and Marisol Sandoval (Eds.). 2011. Internet and Surveillance: The Challenges of Web 2.0 and Social Media. New York: Routledge. ISBN 978-0-415-89160-8. EU COST Publication. 332 pages. http://fuchs.uti.at/books/internet-and-surveillance-the-challenges-of-web-2… With contributions by: Anders Albrechtslund, Thomas Allmer, Mark Andrejevic, David Arditi, Roberto Armengol, Kees Boersma, Miyase Christensen, Christian Fuchs, David W. Hill, AndrC) Jansson, Deborah G. Johnson, David Lyon, Thomas Mathiesen, Marisol Sandoval, IvC!n SzC)kely, Monika Taddicken, Daniel Trottier, Kent Wayland, Rolf H. Weber The publication has been supported by EU COST b European Cooperation in Science and Technology and the EU COST Action IS0807 b Living in Surveillance Societiesb . This book is the first ever published volume that is dedicated to Internet surveillance in the age of what has come to be termed b social mediab or b web 2.0b3 (blogs, wikis, file sharing, social networking sites, microblogs, user-generated content sites, etc). The Internet has been transformed in the past years from a system primarily oriented on information provision into a medium for communication and community-building. The notion of b Web 2.0b, social software, and social networking sites such as Facebook, Twitter and MySpace have emerged in this context. With such platforms comes the massive provision and storage of personal data that are systematically evaluated, marketed, and used for targeting users with advertising. In a world of global economic competition, economic crisis, and fear of terrorism after 9/11, both corporations and state institutions have a growing interest in accessing this personal data. Here, contributors explore this changing landscape by addressing topics such as commercial data collection by advertising, consumer sites and interactive media; self-disclosure in the social web; surveillance of file-sharers; privacy in the age of the internet; civil watch-surveillance on social networking sites; and networked interactive surveillance in transnational space. This book is a result of a research action launched by the intergovernmental network COST (European Cooperation in Science and Technology). -- Prof. Christian Fuchs Chair in Media and Communication Studies Department of Informatics and Media Uppsala University KyrkogC%rdsgatan 10 Box 513 751 20 Uppsala Sweden christian.fuchs(a)im.uu.se Tel +46 (0) 18 471 1019 http://fuchs.uti.at http://www.im.uu.se NetPolitics Blog: http://fuchs.uti.at/blog Editor of tripleC: http://www.triple-c.se Book "Foundations of Critical Media and Information Studies" (Routledge 2011) Book "Internet and Society" (Paperback, Routledge 2010) # distributed via <nettime>: no commercial use without permission # <nettime> is a moderated mailing list for net criticism, # collaborative text filtering and cultural politics of the nets # more info: http://mx.kein.org/mailman/listinfo/nettime-l # archive: http://www.nettime.org contact: nettime(a)kein.org ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [smb@cs.columbia.edu: Skype security evaluation]
by Damien Miller 06 Jul '18

06 Jul '18

On Sun, 23 Oct 2005, Joseph Ashwood wrote: >----- Original Message ----- Subject: [Tom Berson Skype Security Evaluation] > >Tom Berson's conclusion is incorrect. One needs only to take a look at the >publicly available information. I couldn't find an immediate reference >directly from the Skype website, but it uses 1024-bit RSA keys, the coverage >of breaking of 1024-bit RSA has been substantial. The end, the security is >flawed. Of course I told them this now years ago, when I told them that >1024-bit RSA should be retired in favor of larger keys, and several other >people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype "roll its own" entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d --------------------------------------------------------------------- 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> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

Re: [zfs-discuss] zfs eradication
by David Magda 06 Jul '18

06 Jul '18

On Nov 10, 2009, at 20:55, Mark A. Carlson wrote: >Typically this is called "Sanitization" and could be done as part of >an evacuation of data from the disk in preparation for removal. > >You would want to specify the patterns to write and the number of >passes. See also "remanence": http://en.wikipedia.org/wiki/Data_remanence (S)ATA actually has a protocol command ("secure erase") that will cause the disk to over write all of its sectors, and not be usable until its done. This doesn't exist in SCSI / SAS / FC as far as I know. Generally speaking one over write is sufficient to prevent data from being accessible, but various government standards specify anywhere between one and four passes: http://en.wikipedia.org/wiki/Data_erasure Degaussing or complete destruction is usually necessary for the "top secret" stuff. DBAN is a useful (open-source) utility that I tend to recommend for regular folk: http://www.dban.org/ While it could be useful, there are penalties in various jurisdictions for leaking data (especially with government-related stuff), so I'm not sure if Sun would want to potentially expose itself to inappropriate use that doesn't clean everything properly. With ZFS encryption coming up, it could be sufficient to have your data sets encrypted and then simply "forget" the key. The data is still technically there, but (theoretically) completely inaccessible. _______________________________________________ zfs-discuss mailing list zfs-discuss(a)opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ----- 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: [zfs-discuss] zfs eradication
by David Magda 06 Jul '18

06 Jul '18

On Nov 10, 2009, at 20:55, Mark A. Carlson wrote: >Typically this is called "Sanitization" and could be done as part of >an evacuation of data from the disk in preparation for removal. > >You would want to specify the patterns to write and the number of >passes. See also "remanence": http://en.wikipedia.org/wiki/Data_remanence (S)ATA actually has a protocol command ("secure erase") that will cause the disk to over write all of its sectors, and not be usable until its done. This doesn't exist in SCSI / SAS / FC as far as I know. Generally speaking one over write is sufficient to prevent data from being accessible, but various government standards specify anywhere between one and four passes: http://en.wikipedia.org/wiki/Data_erasure Degaussing or complete destruction is usually necessary for the "top secret" stuff. DBAN is a useful (open-source) utility that I tend to recommend for regular folk: http://www.dban.org/ While it could be useful, there are penalties in various jurisdictions for leaking data (especially with government-related stuff), so I'm not sure if Sun would want to potentially expose itself to inappropriate use that doesn't clean everything properly. With ZFS encryption coming up, it could be sufficient to have your data sets encrypted and then simply "forget" the key. The data is still technically there, but (theoretically) completely inaccessible. _______________________________________________ zfs-discuss mailing list zfs-discuss(a)opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss ----- 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: [smb@cs.columbia.edu: Skype security evaluation]
by Damien Miller 06 Jul '18

06 Jul '18

On Sun, 23 Oct 2005, Joseph Ashwood wrote: >----- Original Message ----- Subject: [Tom Berson Skype Security Evaluation] > >Tom Berson's conclusion is incorrect. One needs only to take a look at the >publicly available information. I couldn't find an immediate reference >directly from the Skype website, but it uses 1024-bit RSA keys, the coverage >of breaking of 1024-bit RSA has been substantial. The end, the security is >flawed. Of course I told them this now years ago, when I told them that >1024-bit RSA should be retired in favor of larger keys, and several other >people as well told them. More worrying is the disconnect between the front page summary and the body of the review. If one only reads the summary, then one would only see the gushing praise and not the SSH protocol 1-esque use of a weak CRC as a integrity mechanism (section 3.4.4) or what sounds suspiciously like a exploitable signed vs. unsigned issue in protocol parsing (section 3.4.6). Also disappointing is the focus on the correct implementation of cryptographic primitives (why not just use tested commercial or open-source implementations?) to the exclusion of other more interesting questions (at least to me): - What properties does the proprietary key agreement protocol offer (it sounds a bit like an attenuated version of the SSH-1 KEX protocol and, in particular, doesn't appear to offer PFS). - Does the use of RC4 follow Mantin's recommendations to discard the early, correlated keystream? - How does the use of RC4 to generate RSA keys work when only 64 bits of entropy are collected from Skype's RNG? (Section 3.1) - Why does Skype "roll its own" entropy collection functions instead of using the platform's standard one? - Ditto the use of standard protocols? (DTLS would seem an especially obvious choice). - What techniques (such as privilege dropping or separation) does Skype use to limit the scope of a network compromise of a Skype client? -d --------------------------------------------------------------------- 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> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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

Re: [tor-relays] BitTorrent complaint
by grarpamp 06 Jul '18

06 Jul '18

> Bittorrent may be an exception to the above but the performance cost > would be at the clients end and for one bittorrent is hardly a realtime > protocol a little delay making each connection would not make much > difference, two it performs poorly if you insist on running it over tor > anyway and thirdly the average consumer desktop system is not exactly > lacking spare CPU cycles due to the bursty nature of their workloads > they statistically tend to spend the majority of their time idling. As opposed to torrenting via exits, I'm amazed more people haven't moved their torrenting to operate entirely within anonymous networks. The performance of I2P and Tor (and I guess Phantom during tests) is actually quite usable so long as the user excercises content selection and patience. And regarding this thread, the freedom of operators and users from complaints regarding takedown would be invaluable. I'm not sure if these networks could scale to handle the node count and chatter, but I think the bit about spare cycles is right and might even act as a natural limiter to that sort of traffic. For instance, my tests show that establishing connections to many onions in parallel is quite costly and prone to failure without available headroom. But once connected, things are ok. Perhaps torrenters simply can't put aside their 'must download it all right now' mentality which keeps them away from our nodes. Or there is a major influx waiting to happen upon some future enlightenment whether they're misguided or not. _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ----- 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: Fun with Rosslyn Chapel, or, What *was* the Templar's Cipher,
by T. Wolf 06 Jul '18

06 Jul '18

anyway? Dear RAH, I just found the old attached message of yours doing a web search. Coincidentally, I'm currently looking for the very the same thing (i.e. the ciphers the Templars used for their bearer certificates). Since your message is two years old already, I'm hoping you found the solution by now. If you did, PLEASE PLEASE PLEASE tell me! Thanks, Thomas ----- Your old message (http://archives.neohapsis.com/archives/crypto/2000-q2/0315.html) ----- I'm dong an IBUC shirt for EFCE2K, and, given that we're in Edinburgh, and Rosslyn Chapel, the famous Templar, um, Mecca, is here, and the Templars ran the original money transfer business, using cryptography no less, Fearghas and I popped out to Roslin to root around for stuff to stick on the aforesaid shirt. Close, but, more or less, no cigar. We saw the faded remains of a Templar floriated cross on the Earl of St. Clair's supposed crypt-cover (kinda small, people speculate about all kinds of goodies in there), which might have been cool, but it was all eroded and I haven't found line art of one on the web and it's late. I've gotten a couple kinda-crypto things, of which I'll pick one for the shirt tomorrow morning before we mail it out to the silkscreener, but what I'd *really* like to know, if it's not one of the many "secrets" of the Templars [like the shroud of Turin is DeMolay, or that the Templars were Masons, or vice versa, or that they had the head of John the Baptist (or christ, or Joseph, or the original Green Man) or that they *really* had the Ark of the Covenent, or the Holy Grail, or that DeMolay was the Second Gunman on the Grassy Knoll :-), or, whatever] is... Has anyone ever figured out, or "discovered" or whatever, what kind of cryptosystem the Templars used to encrypt, decrypt, sign/modify the chits (dare I say bearer certificates? ;-)) they used so that people could go from preceptory to preceptory, getting cash/food/whatever, all the way to the holy land (and get the remains of their money back, or a bill :-), when they returned home? Cheers, RAH, Who, oddly enough, and by the sheerest coincidence (and I swear on a stack of Illuminati), lives in the Roslindale section of Boston, named for Roslin, home of Rosslyn Chapel.... --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire' --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com

1 0

[Announce] Introducing Tor VM b Tor in a virtual machine.
by Kyle Williams 06 Jul '18

06 Jul '18

[1]http://www.janusvm.com/tor_vm/ Tor VM is a small virtual machine that acts as a router and redirects your TCP traffic and DNS request through Tor while filtering out protocols that could jeopardize your anonymity. Tor VM is built using all open source software and is free. There are many advantages to running Tor in a virtual machine. Any application on any operating system that uses TCP for communication is routed over Tor. By using a small virtual machine that acts as a router, protocols such as UDP and ICMP are filtered, preventing a compromise of your anonymity. Placing Tor in a virtual machine separates Tor from potentially insecure applications that could compromises Tor's integrity and your security. The Tor VM ISO is designed to be run in a virtual machine, not on physical hardware. The ISO requires two virtual NICs to be used; one bridged interface, one OpenVPN Tun/Tap adapter. The Windows build of Tor VM is portable and includes QEMU to run the virtual machine, but requires Administrator privileges to install the Tap32 adapter. Traffic is routed through the Tap interface, into the VM, TCP and DNS are directed to Tor's Transport while other protocols are discarded, then Tor does it's magic with your traffic. More details can be found in the design documentation. Lots of people are going to ask "What's the difference between JanusVM and Tor VM?", so I'll address this now. JanusVM was designed to be used by multiple users, runs HTTP traffic through Squid and Privoxy, and was build on top of Debian packages. Tor VM is built from entirely 100% open source software, is pre-configured to support only a single user, is much smaller in size, uses less memory than JanusVM, and works with QEMU. Is Tor VM going to replace JanusVM?? It's too soon to tell. This software is in the late alpha stages of development; work is still in progress. For the time being, Tor VM is being hosted on the JanusVM server. Martin and I would appreciate it if a few of you would give Tor VM a go and provide us with your feedback. Feel free to review the We look forward to hearing from the community. One last thing. Mad props to coderman! Martin did an amazing job hacking QEMU and the WinPCAP drivers in order to create an interface that is a raw bridge into the existing network card. This is just as good as VMware bridge service, if not better! It's Amazing work; make sure to take a close look at what is under the hood. Tor VM wouldn't have been possible if it wasn't for his insane amount of knowledge and skill. Let me be the first to say it; Thank You. :) Best Regards, Kyle Williams References 1. http://www.janusvm.com/tor_vm/ ----- 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

Tor's three-year development roadmap
by Roger Dingledine 06 Jul '18

06 Jul '18

Hi folks, I've finally finished writing up our three-year development roadmap. This document describes Tor research and development items that should happen on a three-year timeframe to move Tor forward at being both a useful circumvention tool and a useful privacy tool: https://svn.torproject.org/svn/tor/trunk/doc/roadmaps/2008-12-19-roadmap-fu… We've got enough funding to get good starts on many of the items in the roadmap (more detail on that coming soon), but of course we could use some more to get even further. So if you know anybody interested in these topics, please let them know -- and let us know. :) While The Tor Project makes sure to do a great job at being transparent in our research and design discussions and outcomes ("how Tor works and why" from the researcher perspective), we haven't done as good a job lately at being transparent to our *users* about what we're working on, what we hope to work on next, who's working on what, etc. Hopefully this pdf will help change that. Andrew also produced an actual press release for us, so we can become more press friendly and provide a way for the media to start a conversation with us: https://blog.torproject.org/blog/our-three-year-development-roadmap-publish… https://www.torproject.org/press/2008-12-19-roadmap-press-release You may also be interested to follow the more detailed TODO list I've been maintaining to help keep all the developers coordinated: https://svn.torproject.org/svn/tor/trunk/doc/TODO.external Thanks! --Roger ----- 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