October 2013 - cypherpunks - lists.cpunks.org

remove from list
by Patrick Wells 02 Oct '13

02 Oct '13

1 0

[cryptography] the spell is broken
by Eugen Leitl 02 Oct '13

02 Oct '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Wed, 02 Oct 2013 18:41:21 +0300 From: ianG <iang(a)iang.org> To: Crypto discussion list <cryptography(a)randombit.net> Subject: [cryptography] the spell is broken User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 http://www.infoworld.com/print/228000 October 02, 2013 Silent Circle moves away from NIST cryptographic standards, cites NSA concerns The company plans to replace AES and SHA-2 with Twofish and Skein in its encrypted communication services By Lucian Constantin | IDG News Service Silent Circle, a provider of encrypted mobile Voice over Internet Protocol (VoIP) and text messaging apps and services, will stop using the Advanced Encryption Standard (AES) cipher and Secure Hash Algorithm 2 (SHA-2) hash functions as default cryptographic algorithms in its products. [ Build and deploy an effective line of defense against corporate intruders with InfoWorld's Encryption Deep Dive PDF expert guide. Download it today! | Stay up to date on the latest security developments with InfoWorld's Security Central newsletter. ] "We are going to replace our use of the AES cipher with the Twofish cipher, as it is a drop-in replacement," Silent Circle CTO Jon Callas said Monday in a blog post. "We are going to replace our use of the SHA-2 hash functions with the Skein hash function. We are also examining using the Threefish cipher where that makes sense." The company also plans to stop using P-384, one of the elliptic curves recommended by the NIST for use in elliptic curve cryptography (ECC). ... Silent Circle plans to replace the P-384 elliptic curve with one or more curves that are being designed by cryptographers Daniel Bernstein and Tanja Lange, who have argued in the past that Suite B elliptic curves are weak. "If the Suite B curves are intentionally bad, this would be a major breach of trust and credibility," Callas said. "Even in a passive case -- where the curves were thought to be good, but NSA cryptanalysts found weaknesses they have since exploited -- it would create a credibility gap of the highest order, and would be the smoking gun that confirms the Guardian articles." ... Silent Circle's new decision to move away from AES, SHA-2 and the P-384 curve doesn't mean that these standards are insecure, Callas said in the blog post. "It doesn't mean we think less of our friends at NIST, whom we have the utmost respect for; they are victims of the NSA's perfidy, along with the rest of the free world. For us, the spell is broken. We're just moving on." ... Asked why Twofish and Skein in particular were chosen to be the new default choices for Silent Circle's products, Callas said via email that both algorithms come from trusted sources, including himself in the case of Skein. Twofish was a finalist in the NIST's selection of the AES cipher, and the team that developed it included people that Silent Circle's co-founders personally know and trust, he said. "A number of the same people produced Skein -- which was a SHA-3 finalist -- and I am a member of the Skein team." For Silent Circle this was a "decision of conscience," Callas said. "Our primary responsibility is to protect our customers, especially in the face of uncertainty." _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[cryptome] Cost and Responsibility for Snowden's Breaches
by Eugen Leitl 02 Oct '13

02 Oct '13

----- Forwarded message from John Young <jya(a)pipeline.com> ----- Date: Wed, 02 Oct 2013 08:21:31 -0400 From: John Young <jya(a)pipeline.com> To: cryptome(a)freelists.org Subject: [cryptome] Cost and Responsibility for Snowden's Breaches X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Reply-To: cryptome(a)freelists.org <http://t.co/U9M96oV45K>http://cryptome.org/2013/10/snowden-cost.htm Date: October 1, 2013 9:28:07 AM PDT From: "Jonathan S. Shapiro" <shap[at]eros-os.org> Subject: Cost and Responsibility for Snowden's Breaches Excerpts: "It becomes clear that the damage to *us* was far worse than any cost to the terrorists. In fact, the damage is proportional to your dependence on electronic infrastructure. That's bad. Because it means that people inside our government, at the direction of government officials, sworn to protect and defend the constitution and the country, actively conspired to undermine every segment of the United States along with our key allies. While the run-of-the-mill staff may not have understood this, the more senior people at NSA knew what they were doing. They were certainly told by people on the outside often enough. Frankly, I think some of them should hang. And I mean that literally. These decisions by NSA weren't made by extremist muslims. They were made by people from Harvard, Yale, and Princeton (and elsewhere) right here in America." ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[tor-talk] Tor Weekly News — October 2nd, 2013
by Eugen Leitl 02 Oct '13

02 Oct '13

----- Forwarded message from harmony <harmony01(a)riseup.net> ----- Date: Wed, 02 Oct 2013 12:00:09 +0000 From: harmony <harmony01(a)riseup.net> To: tor-talk(a)lists.torproject.org, tor-news(a)lists.torproject.org Subject: [tor-talk] Tor Weekly News — October 2nd, 2013 Reply-To: tor-talk(a)lists.torproject.org ======================================================================== Tor Weekly News October 2nd, 2013 ======================================================================== Welcome to the fourteenth issue of Tor Weekly News, the weekly newsletter that covers what’s happening in the much-discussed Tor community. Tor Browser Bundle 3.0alpha4 released ------------------------------------- On September 28th, Mike Perry released the fourth alpha of the new Tor Browser Bundle 3.0 series [1]. The main highlights of this series are the important usability improvements that integrate Tor configuration and control into the browser itself, rather than relying on the unmaintained Vidalia interface. The latest iteration is based on Firefox 10.0.9esr, which brings with it a lot of important security fixes. It also fixes a fingerprinting issue by randomizing the timestamp sent when establishing an HTTPS connection. Two small but important usability improvements in the new Tor Launcher component were made: users can now directly copy and paste “bridge” lines from the bridge database [2], while clock-skews that would prevent Tor from functioning properly are now reported to users. Download your copy, test it, and report any problems you find. If you're feeling adventurous, you can also try out the crucial new security process by independently reproducing the binaries from the publicly-reviewable source code [3]. [1] https://blog.torproject.org/blog/tor-browser-bundle-30alpha4-released [2] https://bridges.torproject.org/ [3] https://gitweb.torproject.org/builders/tor-browser-bundle.git/blob/HEAD:/gi… Tor mini-hackathon at GNU 30th anniversary ------------------------------------------ The Tor mini-hackathon at the GNU 30th anniversary event [4] took place over the weekend, and Nick Mathewson sent out a brief report [5] on how things went. As well as working on proposal 220, which involves improvements to Tor server identity keys, Nick merged some small patches into the Tor mainline branch, and collected promises of several more to come. He also directed a few enquiring minds towards Tor's online community, saying “I hope we’ll be seeing more of some of the folks I talked to on our mailing lists and IRC channels soon”. [4] https://lists.torproject.org/pipermail/tor-talk/2013-September/030238.html [5] https://www.gnu.org/gnu30/ Tor Stack Exchange page in private beta --------------------------------------- The Tor Stack Exchange page [6], which reached 100% commitment last week [7], has now been moved into the ‘private beta’ stage. Runa Sandvik clarified that “the purpose behind it is to ensure that users who committed to the site’s proposal have a chance to start asking and answering questions, as well as help with the initial community building activities that will define and shape the site” [8]. She added that “the more experts who participate in the private beta, the more certain it is that our page will move on to the next stage (i.e. the public beta).” Fruitful discussions are already taking place: Karsten Loesing wrote to the wider community on the question of what to do about contact information for bridge operators after it was posed on Stack Exchange. [9] Roger Dingledine put out a call [10] for Tor developers and anonymity researchers to participate in answering questions on the site, adding “Steven, Philipp, Jens, and I can't do it by ourselves.” If you have expert knowledge to contribute, please send an email to help(a)rt.torproject.org to get an invitation! [6] http://tor.stackexchange.com [7] http://area51.stackexchange.com/proposals/56447/tor-online-anonymity-privac… [8] https://lists.torproject.org/pipermail/tor-talk/2013-September/030187.html [9] https://lists.torproject.org/pipermail/tor-relays/2013-September/002936.html [10] https://lists.torproject.org/pipermail/tor-dev/2013-September/005519.html liballium: Pluggable Transports utility library in C ---------------------------------------------------- Yawning Angel announced a new library to ease the task of writing pluggable transports [11]. liballium is a “simple library that handles the Tor Pluggable Transport Configuration protocol. The idea is for this library to be the C/C++ equivalent to pyptlib [12] (and maybe more, depending on how much time I have to work on it).” The code is available for review [13] featuring “a reasonably well commented example.” Feel free to follow up with “questions, comments, feedback”! [11] https://www.torproject.org/docs/pluggable-transports.html [12] https://gitweb.torproject.org/pluggable-transports/pyptlib.git [13] https://github.com/Yawning/liballium Tor Help Desk Roundup --------------------- Multiple users wrote to the help desk asking for guidance setting up hidden service sites. The most straightforward documentation for hidden services is in the torrc file itself [14]. A more in-depth guide can be found on the Tor Project website [15]. The website also documents how hidden services work [16]. Technical details can be found in the Rendezvous Specification document [17]. [14] https://www.torproject.org/docs/faq.html.en#torrc [15] https://www.torproject.org/docs/tor-hidden-service.html.en [16] https://www.torproject.org/docs/hidden-services.html.en [17] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.… Monthly status reports for September 2013 ----------------------------------------- The wave of regular monthly reports from Tor project members for the month of September has begun. Runa Sandvik released her report first [18], followed by reports from Damian Johnson [19], Philipp Winter [20], Sherief Alaa [21], and Noel David Torres Taño [22]. [18] https://lists.torproject.org/pipermail/tor-reports/2013-September/000341.ht… [19] https://lists.torproject.org/pipermail/tor-reports/2013-September/000342.ht… [20] https://lists.torproject.org/pipermail/tor-reports/2013-October/000343.html [21] https://lists.torproject.org/pipermail/tor-reports/2013-October/000344.html [22] https://lists.torproject.org/pipermail/tor-reports/2013-October/000345.html Miscellaneous news ------------------ Mike Perry published his new GPG public key, adding: “this new key will be used to sign email from me going forward, and will be used to sign software releases until such time as I get around to creating a second set of keys on a hardware token for that purpose” [23]. [23] https://lists.torproject.org/pipermail/tor-dev/2013-September/005518.html David Fifield updated the Pluggable Transports bundles using the latest Tor Browser Bundle [24]. In order to benefit from the improvements and security fixes, please update! [24] https://blog.torproject.org/blog/pluggable-transports-bundles-2417-beta-2-p… intrigeri sent a release schedule for Tails 0.21 [25]. The first release candidate should be out on October 20th. [25] https://mailman.boum.org/pipermail/tails-dev/2013-September/003719.html Roger Dingledine sent out “a list of criteria to consider when evaluating pluggable transports for readiness of deployment to users”, asking for comments on his initial draft [26]. [26] https://lists.torproject.org/pipermail/tor-dev/2013-September/005528.html If you have the necessary hardware and want to help Tails out, please test two upcoming features: persistent printer settings [27] and support for more SD card readers (the “sdio” type) [28]. [27] https://mailman.boum.org/pipermail/tails-dev/2013-September/003744.html [28] https://mailman.boum.org/pipermail/tails-dev/2013-September/003757.html Upcoming events --------------- Oct 09-10 | Andrew speaking at Secure Poland 2013 | Warszawa, Poland | http://www.secure.edu.pl/ | Nov 04-05 | 20th ACM Conference on Computer and Communications Security, | Berlin, Germany | http://www.sigsac.org/ccs/CCS2013/ This issue of Tor Weekly News has been assembled by harmony, Lunar, dope457, and Matt Pagan. Want to continue reading TWN? Please help us create this newsletter. We still need more volunteers to watch the Tor community and report important news. Please see the project page [29], write down your name and subscribe to the team mailing list [30] if you want to get involved! [29] https://trac.torproject.org/projects/tor/wiki/TorWeeklyNews [30] https://lists.torproject.org/cgi-bin/mailman/listinfo/news-team -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsusbscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Surveillance
by Juan Garofalo 01 Oct '13

01 Oct '13

Am I right in assuming that the US is the only country who has its own subjects PLUS a good deal of the world under close surveillance? Perhaps the government of china does a similar thing, but obviously only inside china? Other governments like, say, the japanese government or the european governments don't have these clearly nazi surveillance programs?

8 11

[RISKS] Risks Digest 27.50
by RISKS List Owner 01 Oct '13

01 Oct '13

RISKS-LIST: Risks-Forum Digest Tuesday 1 October 2013 Volume 27 : Issue 50 ACM FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS (comp.risks) Peter G. Neumann, moderator, chmn ACM Committee on Computers and Public Policy ***** See last item for further information, disclaimers, caveats, etc. ***** This issue is archived at <http://www.risks.org> as <http://catless.ncl.ac.uk/Risks/27.50.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Cybersecurity should be seen as an occupation, not a profession (Steve Ragan) Cost and Responsibility for Snowden's Breaches (Jonathan S. Shapiro) What Facebook, Twitter, Tinder, Instagram, and Internet Porn Are Doing to America's Teenage Girls (Nancy Jo Sales via Monty Solomon) LAUSD halts home use of iPads for students after devices hacked (Re: Blume, RISKS-27.49) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Mon, Sep 30, 2013 at 2:50 AM From: InfoSec News <alerts(a)infosecnews.org> Subject: Cybersecurity should be seen as an occupation, not a profession, (Steve Ragan) [From Dave Farber's IP list] Steve Ragan, CSO Online, 26 Sep 2013 http://www.csoonline.com/article/740456/cybersecurity-should-be-seen-as-an-… A panel from the National Academy of Sciences, commissioned by the U.S. Department of Homeland Security, says that cybersecurity should be seen as an occupation and not a profession. After being commissioned by the U.S. Department of Homeland Security, a panel from the National Academy of Sciences reported that the cybersecurity field is too young, and the technologies, threats, and actions taken to counter them change too rapidly, for professionalization to be considered. Thus, cybersecurity is an occupation and not a profession. For some organizations, making cybersecurity a profession may provide a useful degree of quality control, the report says, but at the same time, professionalization also imposes barriers, which would prevent talented workers from entering the field at a time when "demand for cybersecurity workers exceeds supply." Sticking to the quality control aspect of the report, professionalization, it says, has the potential to attract workers and establish long-term paths to improving the work force overall, but measures such as standardized education or requirements for certification, have their disadvantages too. ... [According to *Webster's*, an occupation is the principal business of one's life. Is the world's youngest would-be "profession" somehow in the same league as the "world's oldest profession", which might also deserve to be called an occupation -- and that it has occupied such a prominent place in our civilization? One more thought: we have often noted here that software engineering is not really an engineering discipline, although millions of people are occupied with it. Does that mean that software engineering also needs to be termed an occupation rather than a profession? Furthermore, if cybersecurity is really an occupation, then we need to recognize the occupational hazards -- one of which seems to be that every computer user's life is unfortunately being occupied and preoccupied with the collateral damage of the lack of professionalism among computer system developers? (Let's not blame the sys admins, who have a really thankless job under the circumstances in trying to protect systems and networks that are inherently unprotectable.) PGN] ------------------------------ Date: October 1, 2013 9:28:07 AM PDT From: "Jonathan S. Shapiro" <shap(a)eros-os.org> Subject: Cost and Responsibility for Snowden's Breaches [Via Dave Farber's IP] The press has lately been recirculating stories about the dollar damages of the Snowden disclosures. The repudiation of key cryptography standards - the ones that underly our electronic currency exchanges and clearinghouses, and are present in an overwhelming number of products - may in the end cost billions of dollars of damage. Some of the press would have us believe that all of this is Snowden's fault. Better, some feel, to focus attention on the messenger and protect the perpetrator. Or even if not better, easier. It sells more papers to focus on a "David vs. Goliath" story than to examine whether Goliath was actually a Philistine. In compromising these cryptography standards, NSA's alleged goal was to read the electronic communications of terrorists, arms dealers, and other savory characters. In a world of open cryptography standards, the only way to do that was to compromise *everybody*. That includes ordinary citizens, businesses, governments (ours and others), armed forces command and control, domestic and global financial systems, and so on. This goes beyond privacy. Cryptography sits under all of our most essential electronic communications. Focusing on Snowden has people asking "How safe are my secrets from the NSA?" when a more pertinent question might be "Is my bank still safe from the eastern block mafia and the terrorist of the month?" Banks for the most part don't operate by storing dollar bills; they operate electronically. Then there is the power delivery infrastructure, or... the list goes on. *That* is what NSA compromised. And when you understand that, it becomes clear that the damage to *us* was far worse than any cost to the terrorists. In fact, the damage is proportional to your dependence on electronic infrastructure. That's bad. Because it means that people inside our government, at the direction of government officials, sworn to protect and defend the constitution and the country, actively conspired to undermine every segment of the United States along with our key allies. While the run-of-the-mill staff may not have understood this, the more senior people at NSA knew what they were doing. They were certainly told by people on the outside often enough. Frankly, I think some of them should hang. And I mean that literally. These decisions by NSA weren't made by extremist muslims. They were made by people from Harvard, Yale, and Princeton (and elsewhere) right here in America. But there is something worse. In a certain sense, the NSA's primary mission is the discovery of secrets. Being in the secret breaking business, one of the things they know very well is that the best way to break a secret is to get someone to tell you what it is. And there is *always* someone who will tell you, either out of conviction or out of fear of compromise. There was never a question whether the fact that NSA compromised every first world and second world country would leak. The only questions were *who* would leak it and *how soon*. It happened to be Snowden, but if not for Snowden it would have been somebody else. So setting aside the technical damage, there is the fact that the U.S. Government is now known - and more importantly, believed - to have compromised ourselves and our allies. We need to ask what the consequences are of that. Here are some questions that suggest themselves: 1. Cryptography is clearly too important to entrust to the government. Who can we trust? 2. Fragmentation seems likely. Does that help or hinder us? 3. Do the issues differ for communications cryptography vs. long-term storage cryptography? Given that communications is recorded and stored forever, I suspect not. 4. Can our allies ever again trust an American-originated crypto system? Software system? Can we trust one from them? 5. Can our allies ever again afford to trust an American manufacturer of communications equipment, given that every one of the major players seems to have gotten in bed with NSA when pressured to do so by the U.S. Government? 6. What *other* compromised technologies have been promulgated through government-influenced standards and/or back room strong arm tactics? One thing seems clear: we must now choose between the credibility of American technology businesses and the continuation of export controls on cryptography and computer security technology. The controls are ineffective for their alleged purpose; there are too many ways to circumvent them. The main use of these laws has been to allow government pressure to be brought to bear on vendors who won't "play ball" with U.S. Government objectives. As long as the big players in the U.S. computing and networking industries can be be backdoored by their government (take that either way), only a fool would buy from them. If the goal is to destroy the American technology industry, this strategy is even better than software patents. As long as those laws remain on the books, the American tech sector has a credibility problem. A second thing seems clear: we need to move to openly *developed* standards for critical systems, not just open *standards*. And not just openly developed standards, but standards whose "theory of operation" is explained and critically examined by the public. No more unexplained magic tables of numbers. We need fully open public review, and public reference implementations as part of the standardization process. A third thing seems clear: fixing the cryptography doesn't solve the problem. Even with back doors, the best place to break crypto is at the insecure end points. We need to develop information management methods (e.g. "zero knowledge" methods, but also others) and software architectures that let us limit the scope of damage when it occurs. The operating systems - and consequently the applications - that we are using today simply weren't designed for this. Fortunately, the hardware environment has converged enough that we can do a lot better than we have in the past. There will never be perfect security, but we can largely eliminate the exponential advantage that is currently enjoyed by the attacker. Jonathan S. Shapiro ------------------------------ Date: Mon, 30 Sep 2013 10:36:47 -0400 From: Monty Solomon <monty(a)roscom.com> Subject: What Facebook, Twitter, Tinder, Instagram, and Internet Porn Are Doing to America's Teenage Girls (Nancy Jo Sales) Nancy Jo Sales, *Vanity Fair*, 26 Sep 2013 Friends Without Benefits This year, 81 percent of Internet-using teenagers in America reported that they are active on social-networking sites, more than ever before. Facebook, Twitter, Instagram, and new dating apps like Tinder, Grindr, and Blendr have increasingly become key players in social interactions, both online and IRL (in real life). Combined with unprecedented easy access to the unreal world of Internet porn, the result is a situation that has drastically affected gender roles for young people. Speaking to a variety of teenaged boys and girls across the country, Nancy Jo Sales uncovers a world where boys are taught they have the right to expect everything from social submission to outright sex from their female peers. What is this doing to America's young women? ... http://www.vanityfair.com/culture/2013/09/social-media-internet-porn-teenag… ------------------------------ Date: Sun, 29 Sep 2013 13:27:54 -0400 From: Monty Solomon <monty(a)roscom.com> Subject: LAUSD halts home use of iPads for students after devices hacked (Re: Howard Blume, RISKS-27.49) Howard Blume, *LA Times*, 25 Sep 2013 Following news that students at a Los Angeles high school had hacked district-issued iPads and were using them for personal use, district officials have halted home use of the Apple tablets until further notice. It took exactly one week for nearly 300 students at Theodore Roosevelt High School to hack through security so they could surf the Web on their new school-issued iPads, raising new concerns about a plan to distribute the devices to all students in the district. ... http://www.latimes.com/local/lanow/la-me-ln-lausd-ipad-hack-20130925,0,6974… ------------------------------ Date: Sun, 7 Oct 2012 20:20:16 -0900 From: RISKS-request(a)csl.sri.com Subject: Abridged info on RISKS (comp.risks) The ACM RISKS Forum is a MODERATED digest. Its Usenet manifestation is comp.risks, the feed for which is donated by panix.com as of June 2011. => SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) if possible and convenient for you. The mailman Web interface can be used directly to subscribe and unsubscribe: http://lists.csl.sri.com/mailman/listinfo/risks Alternatively, to subscribe or unsubscribe via e-mail to mailman your FROM: address, send a message to risks-request(a)csl.sri.com containing only the one-word text subscribe or unsubscribe. You may also specify a different receiving address: subscribe address= ... . You may short-circuit that process by sending directly to either risks-subscribe(a)csl.sri.com or risks-unsubscribe(a)csl.sri.com depending on which action is to be taken. Subscription and unsubscription requests require that you reply to a confirmation message sent to the subscribing mail address. Instructions are included in the confirmation message. Each issue of RISKS that you receive contains information on how to post, unsubscribe, etc. => The complete INFO file (submissions, default disclaimers, archive sites, copyright policy, etc.) is online. <http://www.CSL.sri.com/risksinfo.html> *** Contributors are assumed to have read the full info file for guidelines. => .UK users may contact <Lindsay.Marshall(a)newcastle.ac.uk>. => SPAM challenge-responses will not be honored. Instead, use an alternative address from which you NEVER send mail! => SUBMISSIONS: to risks(a)CSL.sri.com with meaningful SUBJECT: line. *** NOTE: Including the string "notsp" at the beginning or end of the subject *** line will be very helpful in separating real contributions from spam. *** This attention-string may change, so watch this space now and then. => ARCHIVES: ftp://ftp.sri.com/risks for current volume or ftp://ftp.sri.com/VL/risks for previous VoLume http://www.risks.org takes you to Lindsay Marshall's searchable archive at newcastle: http://catless.ncl.ac.uk/Risks/VL.IS.html gets you VoLume, ISsue. Lindsay has also added to the Newcastle catless site a palmtop version of the most recent RISKS issue and a WAP version that works for many but not all telephones: http://catless.ncl.ac.uk/w/r <http://the.wiretapped.net/security/info/textfiles/risks-digest/> . ==> PGN's comprehensive historical Illustrative Risks summary of one liners: <http://www.csl.sri.com/illustrative.html> for browsing, <http://www.csl.sri.com/illustrative.pdf> or .ps for printing is no longer maintained up-to-date except for recent election problems. *** NOTE: If a cited URL fails, we do not try to update them. Try browsing on the keywords in the subject line or cited article leads. ==> Special Offer to Join ACM for readers of the ACM RISKS Forum: <http://www.acm.org/joinacm1> ------------------------------ End of RISKS-FORUM Digest 27.50 ************************

2 1

Bitmessage?
by d.nix 01 Oct '13

01 Oct '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've seen little or no discussion of Bitmessage, and was wondering what thoughts - pro or con - people have of it: https://bitmessage.org/wiki/Main_Page I've got it up and running and have exchanged messages with a friend and well as a few other folks testing the waters. One thing I like about it, is that it seems at first glance to not suffer from the same sort of traffic analysis issues that plague regular email; to me, the traffic analysis problems are a bigger issue than message encryption. One could also paste PGP/GPG or other encrypted content into Bitmessage for your super duper secret stuff where you are concerned the recipients machine is compromised. There's apparently a standard email gateway for it also: https://bitmessage.ch/ Tho, that may bring you back to the problems of traffic analysis. I'd also love to see more mix network stuff getting developed so we could help secure against traffic analysis of existing systems. Tom Ritter's talk on analyzing mix network traffic was quite cool: http://ritter.vg/blog-deanonymizing_amm.html http://ritter.vg/blog-deanonymizing_amm_followup1.html But anyhow, Bitmessage; yay or nay? Dave BM-2D9fgf9MeGhq9Fxcwg1k2W1C179KJuUEFg - -- -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (MingW32) iQEcBAEBAgAGBQJSSRByAAoJEDMbeBxcUNAeevIH/3RFdqhbuKtlB4ZraFH531zE hdXHfQFOPhAvpV2SjIscm3YMLWnDMR2ap5zRrIZ6OSPThVNa7339q87ITU4sRBAs yCXHJaEFiT/kY/IfGr8PeYLrUegSgY41iGjgYekkZUfIrQdXwlA7afMr4XZz4DKP XsrpE3Mjq8tw9JOgB3q8VzMOaDuCOyIceFxyGiDhlwTlM1Imy4NPGkaToAvkhg4C 51MmXjRW/L+hBhjyeCJ0iG4o1YOhaOIVocsHXYy7n3V7mHmwvrS86cF1i0wpxAxM 3Q/7N7FNM57LEHBgU8xLsGkrmY/FLk0hZLPOz3ZClefhjaQIE9jpz8GHKCXziSw= =8xN+ -----END PGP SIGNATURE-----

2 1

Re: [Cryptography] Why is emailing me my password?
by John Young 01 Oct '13

01 Oct '13

The several crypto lists run by mailman email passwords monthly. Open crypto lists are not meant to be more trustworthy than open crypto. At 10:28 AM 10/1/2013, you wrote: >This falls somewhere in the land of beyond-the-absurd. > >Just got this message from your robot: > >On Oct 1, 2013, at 5:00 AM, mailman-owner(a)metzdowd.com wrote: > > > If you have questions, problems, comments, etc, send them to > > mailman-owner(a)metzdowd.com. Thanks! > > > > Passwords for greg(a)kinostudios.com: > > > > List Password // URL > > ---- -------- > > cryptography(a)metzdowd.com iPoopInYourHat > > http://www.metzdowd.com/mailman/options/cryptography/greg%40kinostudios.com > >So, my password, iPoopInYourHat, is being sent to me in the clear by >your servers. > >Of all the places on the internet, this would be on the last places >I would expect this to happen. > >- Greg > >-- >Please do not email me anything that you are not comfortable also >sharing with the NSA. > > > >_______________________________________________ >The cryptography mailing list >cryptography(a)metzdowd.com >http://www.metzdowd.com/mailman/listinfo/cryptography

1 0

Re: [cryptography] The Compromised Internet
by Eugen Leitl 01 Oct '13

01 Oct '13

----- Forwarded message from The Doctor <drwho(a)virtadpt.net> ----- Date: Mon, 30 Sep 2013 14:14:54 -0400 From: The Doctor <drwho(a)virtadpt.net> To: cryptography(a)randombit.net Subject: Re: [cryptography] The Compromised Internet Organization: Virtual Adept Networks, Unlimited User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 Reply-To: drwho(a)virtadpt.net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/27/2013 09:35 AM, Eugen Leitl wrote: > I don't see how a ham running a repeater backbone can prevent end > to end encryption other than sniffing for traffic and actively > disrupting it. I'm not sure tampering If enough hams (or one sufficiently angry lone ham operator) decide that this is a problem they'll organize a turkey hunt to triangulate the operator(s) and politely ask them to stop before the feds get called in. The thinking behind this seems to be that the amateur community has been graciously granted a small portion of the RF spectrum to experiment with. People (licensed hams or otherwise) who do specifically prohibited things within the amateur bands (like transmitting encrypted traffic or undocumented digital protocols (which may be indistinguishable from encrypted traffic)) can get some or all of the amateur band taken away. A lot of time and effort are spent every year by ham operators who don't want this, that, or the other sliver of the amateur band reassigned away from amateur use, and someone doing something dodgy within those spectra could have disasterous consequences. When Project Byzantium was adding amateur radio support for ISC milestone #3, these regulations were noted and discussed at length during initial reasearch. We also spoke with the ARRL during development, which expressed similar sentiments about crypto in the amateur bands (and passing traffic from unlicensed network users over the amateur band, incidentally). > with transport is within ham ethics, though they definitely That would probably fall under jamming, which is definitely against ham ethics. > don't understand the actual uses for encryption, at The hams I've spoken to seem to, but they also seem to fall into the camp of "It's on the amateur bands, so if it's something I'd want to encrypt I'm not going to talk about it while chewing the rag anyway." > least the old hands (are there even new hands?). Hello. - -- The Doctor [412/724/301/703] [ZS] Developer, Project Byzantium: http://project-byzantium.org/ PGP: 0x807B17C1 / 7960 1CDC 85C9 0B63 8D9F DD89 3BD8 FF2B 807B 17C1 WWW: https://drwho.virtadpt.net/ "Be the strange that you want to see in the world." --Gareth Branwyn -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJJv54ACgkQO9j/K4B7F8GO0wCeMVOKo1YmC+/8VqUcm4+CGBek fk4AnjiH3UGQ/kqSzmSatwKFpSceISBq =n2mL -----END PGP SIGNATURE----- _______________________________________________ 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://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

[Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?)
by Eugen Leitl 01 Oct '13

01 Oct '13

----- Forwarded message from Adam Back <adam(a)cypherspace.org> ----- Date: Tue, 1 Oct 2013 16:26:03 +0200 From: Adam Back <adam(a)cypherspace.org> To: Mark Friedenbach <mark(a)monetize.io> Cc: Bitcoin Dev <bitcoin-development(a)lists.sourceforge.net> Subject: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?) User-Agent: Mutt/1.5.21 (2010-09-15) On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: >This kind of thing - providing external audits of customer accounts >without revealing private data - would be generally useful beyond >taxation. If you have any solutions, I'd be interested to hear them >(although bitcoin-dev is probably not the right place yet). Thanks for providing the impetus to write down the current state, the efficient version of which I only figured out a few days ago :) I have been researching this for a few months on and off, because it seems like an interesting construct in its own right, a different aspect of payment privacy (eg for auditable but commercial sensistive information) but also that other than its direct use it may enable some features that we have not thought of yet. I moved it to bitcointalk: https://bitcointalk.org/index.php?topic=305791.new#new Its efficient finally (after many dead ends): approximately 2x cost of current in terms of coin size and coin verification cost, however it also gives some perf advantages back in a different way - necessary changes to schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs, or k of n multiparty sigs for the verification cost and signature size of one pair of ECS signatures, for n > 2 its a space and efficiency improvement over current bitcoin. Adam ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0