- cypherpunks - lists.cpunks.org

Re: [Cryptography] /dev/random is not robust
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Theodore Ts'o <tytso(a)mit.edu> ----- Date: Wed, 16 Oct 2013 15:11:12 -0400 From: Theodore Ts'o <tytso(a)mit.edu> To: Jerry Leichter <leichter(a)lrw.com> Cc: Sandy Harris <sandyinchina(a)gmail.com>, Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] /dev/random is not robust Message-ID: <20131016191112.GD11604(a)thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) On Wed, Oct 16, 2013 at 01:58:31PM -0400, Jerry Leichter wrote: > > None of this matters much if the enemy does not already have root on > > your system. > Backwards security is a prerequisite for building PFS, among other > things. Without it, if an attacker seizes your system, he can (in > principle, but we're considering *potential capabilities*, not what > we know how to do in detail today) "run the random number generator > backwards".... Actually, the scenario you describe above is called "forward security" in the referenced paper. That's granted. It's also not a problem with Linux's /dev/random, so what you are complaining about is a straw man argument. What I think folks (including myself) are much convinced by is the importance of worrying about the other attacks detailed in the paper, where the attacker is presumed to be able to control the entropy sources to some arbitrary extent. In the case of Linux's /dev/random, that means the the adversary would be able to control the exact timing of interrupts in the system in such a way that the entropy estimators would be fooled. > I'm amazed and disturbed by the nature of the responses to this > paper. They are *indistinguishable* from the typical PR blather we > get from every commercial operation out there when someone reports a > potential attack: It's just theory, it can't be translated into > practice, we have multiple layers of security so even if one of them > can be attacked the others still protect you, yadda yadda yadda. So if someone would like to make a concrete suggestion, I'm certainly willing to entertain a specific proposal. I'll note first of all that FreeBSD's use of Yarrow still uses an entropy estimator, and so it doesn't answer the paper's complaint that "all entropy estimators are crap, and we shouldn't trust any RNG that uses an entropy estimator". I've also said that I might be willing to add some arbitrary threshold were reads to /dev/urandom will block until we estimate that we've received a certain amount of entropy --- although I'd first like to make sure we get as much entropy as possible, so we don't block for too long first. There are some real practical problems on certain embedded platforms where we don't have access to high resolution CPU counters which as far as I'm concerned is a highr priority. This however, is still going to cause academics to kvetch about how we are hopeless, since they disbelieve in entropy estimators and insist on an attack model where the attacker can arbitrarily influence interrupt timing. Furthermore, in the area of the cold start problem, which is the much more real and more practical problem, Fortuna doesn't help, since it in a cold start scenario, it has no idea when it's safe to allow someone to draw from Fortuna --- since in order to do that would rely on an entropy estimator which the academics disbelieve in! > There's always been a strain of anti-academy bias - even > anti-intellectualism - in the OSS community. It's highly > undesirable. There's good academic academic work, and there's bad > academic work. Even with the domain of good academic work, some is > of practical interest today, and some isn't. (And some that isn't > of interest today may be tomorrow.) I prefer to call it "healthy skepticism". As I've said elsewhere, I recall the huge focus on formal verification of computer programs, and the very large number of trees that were killed over that particular academic fad. If we consider the use of techniques that have _actually_ improved security: valgrind, ASLR, static code analysis, how many of them have actually come from academics? The only one I can think of is Coverity, and even there, most of the work was done in a commercial setting, *not* an academic one. (In another area, the academic focus on real-time scheduling (at least five years ago, when I was focusing on that as the technical lead of a Real-Time Linux effort at IBM in support of the US Navy's DDX-1000 next generation destroyer), was completely divergent from what we were actually using in industry. Why? Because by the time the perfect real-time scheduling algorithms were finished running, especially in a dynamic environment, you were pretty much guaranteed to miss *all* of your deadlines and the missle which had popped above the radar horizen unexpectedly would have long ago exploded amidships!) Going back to the random number generators, there are a lot of practical issues, such as making sure the entropy collection is fast enough that downstream kernel engineers and device driver maintainers don't just turn off the entropy collection. This can sometimes happen in embedded kernels, and you might not ever know that this has happened. This is not an academic concern, but it's a real one. On another front, I recently noticed that on my Debian Testing box, the openssl librcrypto library is apparently not using /dev/urandom or /dev/random by default. Hence, if you don't have a ~/.rnd file, any public/private key pairs that you might generate would have no entropy at all! How did I notice this? Because I added a kernel trace point so I could monitor how much use of /dev/random was being used by various userspace progam. I was originally concerned by overuse of /dev/urandom where it wasn't needed, but then I discovered than "openssl genrsa" and "ssh-keygen" is apparently not using /dev/urandom or /dev/random at all(!!!). (Fortunatly this does not appear to be the case on Debian Stable, so it looks like a recent regression. Or maybe it's a misconfiguration on my end, but (a) I'm getting lost trying to figure out the mazy of twisty compile-time and run-time configuration options of OpenSSL, complicated by the Debian packaging system, and (b) even if it is somehow "my fault", it shouldn't be that easy to have things silently fail to have no entropy at all.) So quite frankly, I have much bigger fish to fry, and I have to prioritize my time, since I don't get paid to maintain the Linux random number generator and so my time is not unlimited. > This kind of "shoot the messenger" approach is just plain wrong. > Look at the definition of robustness they come up with and tell me > what parts of it aren't things you'd *like* to get in your RNG, if > you could. Can you come up with anything beyond hand-waving to show > that the Linux RNG actually provides you with those properties? #1. I've read through the paper, and the there is nothing new in the paper that I consider as something I'd like in the RNG. I do care about what they call "forwards security", where compromise of the random state pool does not compromise past results. That's not a new requirement, and it's one which I'm satisfied that we meet. #2. I'm not obligated to prove to *you* anything. I don't get paid or my prospects for promotion do not go up by spending hours writing an peer-reviewed paper. So if you are demanding a formal proof, in the form of an academic paper, instead of "mere handwaving", you can demand anything you want. I get demands for free programming efforts for pet features to my OSS code all the time, and I know how to handle such requests/demands. #3. Let me turn this around, and ask *you* to give me concrete suggestions about changes you'd like to make, preferably in the form of a patch. I'll tell you right away that both Fortuna and Yarrow, which use crypto hashing in the entropy mixing step, is going to be a non-starter from a performance point of view. It's not hypothetical when I talk about embedded shops demanding of their Linux kernel developers That they disable entropy collection. That has actually happened, and I've engaged said embedded kernel developer who got pressure from his management to do this on LKML to try to address that particular concern. To that end, I've made the entropy collection even lighter-weight that will be merged into the next kernel merge window, and I believe I've done it in a way that preserves our security properties. So when you ask me to worry about a hypothetical attack where an adversary might be able to control all interrupt timing, and I'm dealing with an actual attack where the adversary (also known as the product manager :-) demanding that entropy collection be disabled, please don't be offended when I don't take you all that seriously. Especially when the "academically approved" RNG's don't fare all that well in a world where all entropy estimators are f*cked and interrupt timing and other entropy sources are subject to fine-grained control by the remote attacker. (Even Fortuna, if you are worried about the cold start problem.) Regards, - Ted P.S. If you actually read the /dev/random source code, and take a look at the git commit logs, you'll see that I have made changes in response to academic papers, and I make sure to give them full credit in the comments. My bias only comes because I've seen so much academic work which has very little relationship to the problems that I need to worry about as a practicing engineer. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/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

Re: [p2p-hackers] Distributed identity, chat, publishing, and sharing
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from ianG <iang(a)iang.org> ----- Date: Thu, 17 Oct 2013 11:01:15 +0300 From: ianG <iang(a)iang.org> To: p2p-hackers(a)lists.zooko.com Subject: Re: [p2p-hackers] Distributed identity, chat, publishing, and sharing Message-ID: <525F994B.1070906(a)iang.org> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 Reply-To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> Just some thoughts. I wasn't able to find my original post asking that question... On 16/10/13 22:50 PM, Sean Lynch wrote: > ianG <iang(a)iang.org> writes: > >> BTW, why the keenness on Ed25519? > > Sorry for the delayed response. I managed to lose track of this message > migrating between Gmail and my own server. > > I like Ed25519 because the public keys are 255 bits long, which makes > them potentially usable directly as identifiers. However, more recent > events have changed my thinking on this. Schneier speculates that one of > the NSA's breakthroughs the Snowden documents talks about may be an > advance in the cryptanalysis of ECC systems, and he recommends sticking > with better-studied, more conventional systems based on the conventional > discrete logarithm problem. The NSA/Snowden disclosures is a very dynamic area and our understanding is changing as new info comes in. FWIW, I think this is more likely the case: NSA successfully moved the world across to *standards based* ECC. This concentrates the target, and gave them a chance to influence the nature and direction of the production of constants, sizes and so forth. Back in the early 2000s, ECC was hot, as the CEO of RSA has infamously said, and everyone just took the wisdom of NSA without question. But now there has been a lot of work done by a lot of open mathematicians. What they are discovering is that ECC is quite finicky, and the standards-based curves are rapidly starting to look less shiny. Hence, picking an independent effort that utilises all this last-decade work, and generates independent curves, is possibly a better way to go. http://safecurves.cr.yp.to/ (Remember, however, you have to decide how much you care about the NSA as being your threat model. 1. Is it a sole, life threatening threat? 2. Or is it just a great target? 3. Or is it meaningless? They have the data anyway? There are very few systems that are building for the first case. Most of us would be happy with choosing the type 2 threat model, in which case we can just pick the state of the art (curves) implement and move on.) > On top of that, given the dynamic nature of cryptographic technology, > it's probably not a good idea to lock oneself into a particular > cryptosystem or hash scheme or even to require that identifiers be keys > themselves. I disagree. The history of agility has been poor, IMHO. Instead, I suggest that you lock yourself into the best possible system on today's knowledge -- it's your job, do it! -- and then plan on a complete refit in say 7 years time. Any problems that come up won't be predictable, and you'll not be able to do more than complicate everything anyway. http://iang.org/ssl/h1_the_one_true_cipher_suite.html Good work has sustained far better than we typically give credit for, and bad work has been maintained into a dog's breakfast, without giving damnation due to it. > An identifier scheme could support Ed25519 as one > particularly convenient key type, but eventually we'll want to support > fingerprints as identifiers and fetching of public keys from a DHT. That's a separate question -- where the authentication resides. As a thought experiment, I really like the conceptual approach taken by tcpcrypt which (in short) does an ephemeral lower layer, and provides the params up to a higher layer (application) at which the auth questions can be handled. As it states, authentication is an application level concept, not a lower layer concept. iang _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- 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] Roger's status report, September/October 2013
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Roger Dingledine <arma(a)mit.edu> ----- Date: Thu, 17 Oct 2013 02:47:15 -0400 From: Roger Dingledine <arma(a)mit.edu> To: tor-talk(a)lists.torproject.org Cc: tor-reports(a)lists.torproject.org Subject: [tor-talk] Roger's status report, September/October 2013 Message-ID: <20131017064715.GD31806(a)moria.seul.org> User-Agent: Mutt/1.5.20 (2009-06-14) Reply-To: tor-talk(a)lists.torproject.org Six things I did in September/October 2013: 1) Released Tor 0.2.4.17-rc: https://lists.torproject.org/pipermail/tor-talk/2013-September/029857.html including writing the fix to prioritize NTor handshakes so Tor 0.2.4.x remains usable despite the five million new bot users: https://trac.torproject.org/projects/tor/ticket/9574 Released Tor 0.2.5.1-alpha: https://lists.torproject.org/pipermail/tor-talk/2013-October/030269.html 2) Wrote many blog posts: https://blog.torproject.org/blog/how-to-handle-millions-new-tor-clients with a follow-up summary at http://tor.stackexchange.com/questions/115/how-to-prevent-the-mevade-botnet… https://blog.torproject.org/blog/tor-nsa-gchq-and-quick-ant-speculation https://blog.torproject.org/blog/tor-and-silk-road-takedown https://blog.torproject.org/blog/yes-we-know-about-guardian-article https://blog.torproject.org/blog/lifecycle-of-a-new-relay https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… and also answered hundreds of blog comments / questions. 3) Talked to many many journalists to explain Tor and the Internet. My most useful quotes went to Bruce Schneier: http://www.theguardian.com/world/2013/oct/04/nsa-gchq-attack-tor-network-en… and Brian Fung: http://www.washingtonpost.com/blogs/the-switch/wp/2013/09/06/the-feds-pays-… and Dan Goodin: http://arstechnica.com/security/2013/10/how-the-nsa-might-use-hotmail-or-ya… 4) Helped the Tor Stack Exchange beta get off the ground: http://tor.stackexchange.com/ I zipped up to 1000+ reputation from answering questions in the first few days, but then I disappeared because I was distracted by other work. Hopefully other people have filled in the gap. 5) Helped sort out the 2013 Q4 budget, and also get the new SponsorO projects off the ground: https://trac.torproject.org/projects/tor/wiki/org/sponsors/Otter 6) Attended the SponsorF "red team assessment" where they funded some smart DPI developers to evaluate and try to break Obfsproxy and Flash Proxy. So far so good -- one of the outcomes is that we should set up a performance testbed for Flash Proxy to see if we can replicate their "sometimes when I upload a bunch of stuff it takes a long time" behavior. I plan to talk to Arlo, once I'm back online, about doing that. ------------------------------------------------------------------------- Seven smaller things I did in September/October 2013: 7) Did a talk at PLUG: http://www.phillylinux.org/meetings.html 8) Sorted out a potential anonymity issue that is a great use case for the TorPS path calculator: https://lists.torproject.org/pipermail/tor-dev/2013-September/005475.html https://trac.torproject.org/projects/tor/ticket/9777 but then haven't followed up yet. 9) Helped a bit with the EPIC BBG FOIA press fuss, which ended with: http://epic.org/2013/09/epic-foia-request-reveals-no-e.html Now ya'll can read the analysis I wrote for BBG of why no single organization should run too many Tor relays: http://epic.org/foia/Tor_Docs.pdf 10) Submitted a 30c3 talk with Jake. Hopefully we'll do a big-room talk where we can lay out all the Tor myths and confusions of 2013. 11) Refused my invite to the IEEE Security & Privacy (Oakland) 2004 Program Committee because of IEEE's anti-science publishing policy: http://www.researchwithoutwalls.org/ 12) Posted a list of "Criteria for prioritizing pluggable transport work": https://lists.torproject.org/pipermail/tor-dev/2013-September/005528.html 13) Helped Arlo move forward with his https://check2.torproject.org/ alternative Tor Check implementation. I sure am looking forward to the time when he thinks it's ready to go live. ------------------------------------------------------------------------- I am going offline now for roughly the rest of October. --Roger -- tor-talk mailing list - tor-talk(a)lists.torproject.org To unsubscribe 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

Re: Curious use of cpunks list [Brian Carroll]
by John Young 17 Oct '13

17 Oct '13

By far all reputable and objective polls, affirmed by Rushmore big heads Bruce Schneier and Glenn Greenwald, confirm online usage is totally schizophrenic, escapist, indolent, idle, pointless, still it far outdistances all alternatives in the race to maximize and deny blood doping, elbowing competitors, hiring fans to run naked on TV, lying recantations about never using self-loathing enhancers. Diagnosis: crypto dependency, cold dead hands, N =/ P, PK idolatry, carpal tunnel mentality, ego aerostated by panoptic auto-sphrincterism. Brian Carroll, occasionally self-titled Brain Carroll, is a very smart and polite gentleman who does not mind fools fooling themselves psychobabbling like paranormal tricyclists monomaniacal about can there ever be reliable RNGs.

4 3

Re: [Cryptography] /dev/random is not robust
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Jerry Leichter <leichter(a)lrw.com> ----- Date: Wed, 16 Oct 2013 13:58:31 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: Sandy Harris <sandyinchina(a)gmail.com> Cc: Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] /dev/random is not robust Message-Id: <D3EECDC9-C637-48F5-B3E6-458F93E1C0A4(a)lrw.com> X-Mailer: Apple Mail (2.1510) On Oct 16, 2013, at 8:49 AM, Sandy Harris <sandyinchina(a)gmail.com> wrote: > From the paper: > > " Several security notions have been defined: > " – Resilience: an adversary must not be able to predict future PRNG > outputs even if he can influence the entropy source used to initialize > or refresh the internal state of the PRNG; > " – Forward security ( resp. backward security): an adversary must not > be able to predict past (resp. future) outputs even if he can > compromise the internal state of the PRNG. > " ... Barak and Halevi [BH05] model a PRNG with input ... and define a > new security property called robustness that implies resilience, > forward and backward security. This property actually assesses the > behavior of a PRNG after compromise of its internal state ... > > None of this matters much if the enemy does not already have root on > your system. Backwards security is a prerequisite for building PFS, among other things. Without it, if an attacker seizes your system, he can (in principle, but we're considering *potential capabilities*, not what we know how to do in detail today) "run the random number generator backwards", which would allow any keys that were created using the RNG - like those created in "secure" DH negotiations, for example - to be generated. (But keep in mind the adage: Attacks only get better.) > If an enemy does have root, he has far better targets > than the RNG available and the defenders have bigger worries. Without > root, he cannot see the internal state and, if you use the typical > setup where some saved entropy from last time is pumped in by the boot > scripts, he cannot read that file and using it seems to complicate the > state enough for security.... Also, the definition of resilience mentions an adversary who "can influence the entropy source" but the random(4) driver uses multiple sources so the degree of influence is generally limited.... I'm amazed and disturbed by the nature of the responses to this paper. They are *indistinguishable* from the typical PR blather we get from every commercial operation out there when someone reports a potential attack: It's just theory, it can't be translated into practice, we have multiple layers of security so even if one of them can be attacked the others still protect you, yadda yadda yadda. Yes, this is a theoretical attack. Yes, the Linux RNG is much more complex than the attackers assume in their model. (Complexity is a good thing?) No, no one is likely to be able to be able to use the attack actually get much out of the Linux RNG. But attacks only get better. The fact is, the Linux RNG, like all the "stir entropy into the pool" RNG's out there, were developed in an essentially ad hoc fashion, without even a solid idea of what the desired properties of such a primitive are supposed to be. This paper is a step along a path begun in 2005 by Barak and Halevi (the instant paper has extensive references), and, frankly, it's about time. For such RNG's we've been in about the same position we were in for ciphers in the 1980's and even beyond, before a great deal of theoretical effort got us to characterizations like IND-CPA and all sorts of excellent work on tight reductions and concrete security. There's always been a strain of anti-academy bias - even anti-intellectualism - in the OSS community. It's highly undesirable. There's good academic academic work, and there's bad academic work. Even with the domain of good academic work, some is of practical interest today, and some isn't. (And some that isn't of interest today may be tomorrow.) This kind of "shoot the messenger" approach is just plain wrong. Look at the definition of robustness they come up with and tell me what parts of it aren't things you'd *like* to get in your RNG, if you could. Can you come up with anything beyond hand-waving to show that the Linux RNG actually provides you with those properties? Suppose someone was able to build on the current paper's work and design a Linux RNG that actually *did* provide those properties, with performance comparable to what we have today? That's how, for example, we've gotten beyond the old, ineffective Modes of Operation to modern ones that have actual security techniques. Wouldn't it be nice to be able to make the same transition for RNG's? How will we ever do so without the initial work of the theoreticians to provide a target to aim for? -- Jerry _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/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

[RISKS] Risks Digest 27.54
by RISKS List Owner 17 Oct '13

17 Oct '13

RISKS-LIST: Risks-Forum Digest Wednesday 16 October 2013 Volume 27 : Issue 54 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.54.html> The current issue can be found at <http://www.csl.sri.com/users/risko/risks.txt> Contents: Adi Shamir Prevented from Attending Crypto and Cryptology Conferences (PGN) An App That Saved 10,000 Lives (Amy O'Leary via Monty Solomon) >From the Start, Signs of Trouble at Health Portal (Pear et al. via Monty Solomon) Deloitte IT projects plagued with troubles around the country (Woolhouse and Healy via Monty Solomon) Online Application Woes Make Students Anxious and Put Colleges Behind Schedule (Lauren Weinstein) Deutsche Telekom hopes to hide German Internet traffic from spies (Lauren Weinstein) "We can't let the Internet become Balkanized" (Sascha Meinrath via NNSquad) "Risk considerations: Tracking services monitor your every move" (Steve Ragan via Gene Wirchenko) Abridged info on RISKS (comp.risks) ---------------------------------------------------------------------- Date: Wed, 16 Oct 2013 9:43:36 PDT From: "Peter G. Neumann" <neumann(a)csl.sri.com> Subject: Adi Shamir Prevented from Attending Crypto and Cryptology Conferences Adi Shamir applied for a J1 visa at the beginning of June 2013, two and one-half months early, so that he could attend the annual Crypto Conference in Santa Barbara in mid-August (which he has almost always attend for the past 32 years) and a subsequent NSA-affiliated History of Cryptography Conference -- at which he was to present his paper, The Cryptology of John Nash from a Modern Perspective. As the S in RSA, and one of the most important cryptographers in the world, it would seem to be a no-brainer that he should be present for both conferences. However, he was unable to attend either, because the U.S. took exactly *four* months to send him his new visa. In his apology <http://www.fas.org/sgp/news/2013/10/shamir.html> (dated 15 Oct 2013) for not being able to attend the History of Cryptography conference, Adi notes that "I am not alone, and many foreign scientists are now facing the same situation." Because of the delay, his paper was removed from the program for the History conference. Even though his visa has now arrived long after Crypto 2013, he was reinvited to give the talk at the Cryptology History conference, it is apparently no longer possible due to other commitments. This could be some sort of egregious combination of incredible arrogance, ignorance, stupidity, personal vendetta, diplomatic blunder, and misguided attitude to International scientific collaboration, or possibly just attributable to a serious miscarriage of innate bureaucracy. In any case, the injustice is really sad, because four months for the simple nth renewal of a visa seems outrageous. Indeed, public-key cryptography might not even be with us today if Adi had not been involved with Ron Rivest and Leonard Adleman so long ago. [PGN's personal opinion] ------------------------------ Date: Mon, 14 Oct 2013 10:11:16 -0400 From: Monty Solomon <monty(a)roscom.com> Subject: An App That Saved 10,000 Lives (Amy O'Leary) [Note: RISKS always solicits success stories, particularly those that result from foresight, long-term planning, intelligent software development and software engineering practices, and so on. Here's one. Unfortunately, the norm seems to be that we generally run items on actual cases were the risks are either exacerbated or evidently present, as more or less dominated by the rest of this issue -- because they are predominant. PGN] [Source: Amy O'Leary, *The New York Times*, 5 Oct 2013] While most start-ups feverishly track figures like the total number of users, Ron Gutman, the founder and chief executive of the health information start-up, HealthTap, is more interested in a different data point. This week, the start-up heard from its 10,000th user who said the site saved her life. "My local doctor brushed me off and told me it was anxiety without doing any tests at all," wrote one woman who turned to HealthTap after seeing her doctor. After spending two hours on HealthTap, she was told by a doctor who contributes to the site that her condition sounded like a blocked artery. She soon saw a cardiology specialist who later inserted a coronary stent. Since its founding in 2012, the site has logged nearly a billion questions and answers, from simple queries about headaches or the flu, to more complicated ones, like whether mechlorethamine is a cancer medication. Questions are then routed to a physician who is both an expert in that particular field of medicine, and who is determined by an algorithm to be likely to respond fast, Mr. Gutman said. None of that would be possible without the participation of nearly 50,000 doctors who contribute their advice free. (Every page on the site has a disclaimer saying that the site "does not provide medical advice, diagnosis or treatment.") ... http://bits.blogs.nytimes.com/2013/10/05/how-to-save-10000-lives-with-an-ap… ------------------------------ Date: Sun, 13 Oct 2013 23:16:39 -0400 From: Monty Solomon <monty(a)roscom.com> Subject: From the Start, Signs of Trouble at Health Portal (Pear et al.) Robert Pear, Sharon LaFraniere and Ian Austen. *The New York Times*, dated 12 Oct 2013, published 13 Oct 2013 WASHINGTON - In March, Henry Chao, the chief digital architect for the Obama administration's new online insurance marketplace, told industry executives that he was deeply worried about the Web site's debut. "Let's just make sure it's not a third-world experience," he told them. Two weeks after the rollout, few would say his hopes were realized. For the past 12 days, a system costing more than $400 million and billed as a one-stop click-and-go hub for citizens seeking health insurance has thwarted the efforts of millions to simply log in. The growing national outcry has deeply embarrassed the White House, which has refused to say how many people have enrolled through the federal exchange. Even some supporters of the Affordable Care Act worry that the flaws in the system, if not quickly fixed, could threaten the fiscal health of the insurance initiative, which depends on throngs of customers to spread the risk and keep prices low. ... http://www.nytimes.com/2013/10/13/us/politics/from-the-start-signs-of-troub… ------------------------------ Date: Mon, 14 Oct 2013 10:01:01 -0400 From: Monty Solomon <monty(a)roscom.com> Subject: Deloitte IT projects plagued with troubles around the country (Woolhouse and Healy) 6 Oct 2013 http://www.boston.com/business/technology/2013/10/06/deloitte-projects-plag… Mass. IT project is latest black eye for Deloitte By Megan Woolhouse and Beth Healy | GLOBE STAFF 07 Oct 2013 http://www.bostonglobe.com/business/2013/10/06/deloitte-projects-plagued-wi… State senate committee to hold hearing on troubled Deloitte unemployment system contract October 3, 2013 http://www.boston.com/business/2013/10/03/state-senate-committee-hold-heari… A thousand defects: DOR fired Deloitte in August October 3, 2013 http://www.boston.com/news/local/massachusetts/2013/10/04/thousand-defects-… $54m later, state fired computer contractor By Megan Woolhouse and Beth Healy | GLOBE STAFF 04 Oct 2013 http://www.bostonglobe.com/business/2013/10/03/thousand-defects-dor-fired-d… Massachusetts, California jobless benefit claim woes both tied to Deloitte Consulting of New York 24 Sep 2013 http://www.boston.com/business/news/2013/09/24/troubled-calif-unemployment-… Mass., Calif. benefit claim woes tied to same firm By Megan Woolhouse | GLOBE STAFF 25 Sep 2013 http://www.bostonglobe.com/business/2013/09/24/troubled-calif-unemployment-… Flawed contract for jobless claim system cost state millions By Beth Healy and Megan Woolhouse | GLOBE STAFF 19 Sep 2013 http://www.bostonglobe.com/business/2013/09/18/flawed-contract-leads-flawed… ------------------------------ Date: Sun, 13 Oct 2013 09:43:32 -0700 From: Lauren Weinstein <lauren(a)vortex.com> Subject: Online Application Woes Make Students Anxious and Put Colleges Behind Schedule With early admission deadlines looming for hundreds of thousands of students, the new version of the online Common Application shared by more than 500 colleges and universities has been plagued by numerous malfunctions, alarming students and parents and putting admissions offices weeks behind schedule "It's been a nightmare," Jason C. Locke, associate vice provost for enrollment at Cornell University. "I've been a supporter of the Common App, but in this case, they've really fallen down." http://j.mp/1bPUA3f (*The New York Times* via NNSquad) So, like, this is rocket science to do correctly at these volumes of transactions for relatively straightforward applications? Uh, no. ------------------------------ Date: Sun, 13 Oct 2013 11:43:27 -0700 From: Lauren Weinstein <lauren(a)vortex.com> Subject: Deutsche Telekom hopes to hide German Internet traffic from spies "One of Deutsche Telekom's competitors, Internet service provider QSC, had questioned the feasibility of its plan to shield Internet traffic, saying it was not possible to determine clearly whether data was being routed nationally or internationally, WirtschaftsWoche magazine reported." http://j.mp/1ajC10H (Reuters via NNSquad) What they really mean is foreign spies. Their own vast surveillance apparatus of course would have full access. No matter, it's basically impractical, as noted. ------------------------------ Date: Mon, 14 Oct 2013 08:28:54 -0700 From: Lauren Weinstein <lauren(a)vortex.com> Subject: "We can't let the Internet become Balkanized" (Sascha Meinrath) http://j.mp/1elH7hh (Slate via NNSquad) "Traditionally, that debate has featured America in the role as champion of a free and open Internet, one that guarantees the right of all people to freely express themselves. Arguing against that ideal: repressive regimes that have sought to limit connectivity and access to information. The NSA's actions have shifted that debate, alienating key Internet-freedom allies and emboldening some of the most repressive regimes on the planet. Think of it as an emerging coalition between countries that object to how the United States is going about upholding its avowed principles for a free Internet, and countries that have objected to those avowed principles all along." - - - It is my personal belief that much of the breathless foreign government hyperbole against the US relating to surveillance has little do with actual surveillance (after all, many of these countries have their own major surveillance systems, sometimes focused specifically inward to further political repression and censorship) and everything to do with pushing the abhorrent UN/ITU agenda (or similar agendas) for Internet control that would codify censorship and heavy-handed government directed dictates over Internet content and associated retribution against Internet users. China's and Russia's longstanding duplicity in these respects relating to Internet governance and censorship is particularly noteworthy. ------------------------------ Date: Mon, 14 Oct 2013 13:16:24 -0700 From: Gene Wirchenko <genew(a)telus.net> Subject: "Risk considerations: Tracking services monitor your every move" (Steve Ragan) Steve Ragan, CSO Online, 14 Oct 2013 Tracking services offer no real value to the business, but they exist on networks both large and small, and administrators are often unaware of their presence http://www.csoonline.com/article/741140/risk-considerations-tracking-servic… ------------------------------ 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.54 ************************

1 0

Curious use of cpunks list [Brian Carroll]
by grarpamp 17 Oct '13

17 Oct '13

Please consider writing a whitepaper on the subject of whatever it is you're trying to say and then posting a link to it here with a one paragraph summary for readers. And if you are, or rather than, using this list (as previously surmised by others) as the rough equivalent of your own numbers station, there are surely better places to broadcast this material... nntp, a hidden service webpage, an actual numbers list (which you could ask the cpunks maintainer to set up). Curiosities are presumably welcome here, but really, this? The archives do not indicate much of an audience. Perhaps I've missed something? So I defer to any simple on topic summary and/or explanation which might move others to go back and digest it all for its suggested value and comment therein.

9 8

Re: Bitcoin mining efficiency and Botnets
by Softy 17 Oct '13

17 Oct '13

I hope others point this out, the cost of gold ( nor any other commodity ) is so simplisticly tied to the price of production. Without doing any googling for specific numbers: - the price rise of gold in the past decade. - is the production costs of mining gold getting more or less expensive? alright ... here are some numbers: total cost of production example: 670 per ounce need I quote the current price of gold per ounce? Note, that AISC is just one regions cost - others are plus or minus a hundred or so. http://www.trefis.com/stock/abx/articles/206888/an-analysis-of-barrick-gold… and in pretty pictures: http://www.visualcapitalist.com/what-is-the-cost-of-mining-gold It is the 'other factors' of commodities which drive prices. Biggest is the cartel which controls that particular commodity - think diamonds for easy picture, Read about Libor, ISD etc: http://www.rollingstone.com/politics/news/everything-is-rigged-the-biggest-… -daniel

2 1

Re: [Cryptography] "/dev/random is not robust"
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from John Gilmore <gnu(a)toad.com> ----- Date: Mon, 14 Oct 2013 18:53:58 -0700 From: John Gilmore <gnu(a)toad.com> To: dj(a)deadhat.com Cc: tytso(a)mit.edi, Cryptography List <cryptography(a)metzdowd.com>, cryptography(a)randombit.net Subject: Re: [Cryptography] "/dev/random is not robust" Message-Id: <201310150153.r9F1rwqQ011302(a)new.toad.com> > http://eprint.iacr.org/2013/338.pdf I'll be the first to admit that I don't understand this paper. I'm just an engineer, not a mathematician. But it looks to me like the authors are academics, who create an imaginary construction method for a random number generator, then prove that /dev/random is not the same as their method, and then suggest that /dev/random be revised to use their method, and then show how much faster their method is. All in all it seems to be a pitch for their method, not a serious critique of /dev/random. They labeled one of their construction methods "robustness", but it doesn't mean what you think the word means. It's defined by a mess of greek letters like this: Theorem 2. Let n > m, , ?? ??? be integers. Assume that G : {0, 1}m ??? {0, 1}n+ is a deterministic (t, ??prg )- pseudorandom generator. Let G = (setup, refresh, next) be defined as above. Then G is a ((t , qD , qR , qS ), ?? ??? , ??)- 2 robust PRNG with input where t ??? t, ?? = qR (2??prg +qD ??ext +2???n+1 ) as long as ?? ??? ??? m+2 log(1/??ext )+1, n ??? m + 2 log(1/??ext ) + log(qD ) + 1. Yeah, what he said! Nowhere do they seem to show that /dev/random is actually insecure. What they seem to show is that it does not meet the "robustness" criterion that they arbitrarily picked for their own construction. Their key test is on pages 23-24, and begins with "After a state compromise, A (the adversary) knows all parameters." The comparison STARTS with the idea that the enemy has figured out all of the hidden internal state of /dev/random. Then the weakness they point out seems to be that in some cases of new, incoming randomness with mis-estimated entropy, /dev/random doesn't necessarily recover over time from having had its entire internal state somehow compromised. This is not very close to what "/dev/random is not robust" means in English. Nor is it close to what others might assume the paper claims, e.g. "/dev/random is not safe to use". John PS: After attending a few crypto conferences, I realized that academic pressures tend to encourage people to write incomprehensible papers, apparently because if nobody reading their paper can understand it, then they look like geniuses. But when presenting at a conference, if nobody in the crowd can understand their slides, then they look like idiots. So the key to understanding somebody's incomprehensible paper is to read their slides and watch their talk, 80% of which is often explanations of the background needed to understand the gibberish notations they invented in the paper. I haven't seen either the slides or the talk relating to this paper. _______________________________________________ The cryptography mailing list cryptography(a)metzdowd.com http://www.metzdowd.com/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

3 2

The NSA's New Code Breakers
by Eugen Leitl 16 Oct '13

16 Oct '13

(thank, John, worth reposting full-text) http://www.foreignpolicy.com/articles/2013/10/15/the_nsa_s_new_codebreakers… The NSA's New Code Breakers America's using front companies, break-in artists, and hacktivists to spy on everyone -- and only North Korea seems able to resist. BY MATTHEW M. AID | OCTOBER 15, 2013 There was a time when the code breakers of the National Security Agency actually took the lead in solving enemy encryption systems. These days, not so much. In today's NSA, it's hackers, break-in artists, corporate liaisons, and shadow salesman using front companies who are at the forefront of this effort. Even so-called "hacktivists" play an unwitting role in helping the NSA gain access to computer networks -- both hostile and friendly. Just about the only place that's somewhat immune to the NSA's new style of code-breaking attacks? North Korea, because it's so disconnected from the rest of the world's networks. Former U.S. intelligence officials confirm that the more than 1,500 cryptanalysts, mathematicians, scientists, engineers, and computer technicians who comprise NSA's elite cryptanalytic unit, the Office of Cryptanalysis and Exploitation Services (S31), have had a remarkably large number of code-breaking successes against foreign targets since the 9/11 attacks. But these wins were largely dependent on clandestine intelligence activities for much of their success in penetrating foreign communications networks and encryption systems, and not the more traditional cryptanalytic attacks on encrypted messages that were the norm during the Cold War era. Prior to 9/11, NSA's cryptanalysts used their huge stable of supercomputers to break cipher systems using what is referred to as "brute force methods" -- using the super computers to run every cipher permutation until the message or messages in question become readable. It was a long, tedious, and extremely costly process (today NSA spends over $247 million a year to buy and maintain its state-of-the-art supercomputer systems just for cryptanalytic use). But it did work if there were inherent vulnerabilities or structural weakness in the cipher being attacked, or if the system's users did not practice proper communications security procedures, such as changing the cipher keys and passwords frequently. The NSA today has more supercomputers than ever and the agency still employs a number of puzzle-solvers, linguists, and math geeks. But these classic cryptanalysts have, in part, given way to a new breed. You won't learn this in the files leaked by former NSA contractor Edward Snowden -- at least not directly. According to individuals who have reviewed the entire collection of 50,000 documents provided to the media by Snowden, what is missing from the papers is any document which lays out in detail just how successful the agency's code-breaking efforts have been. There are numerous documents in the Snowden collection describing individual NSA cryptologic programs, such as NSA's mostly unsuccessful multi-year effort to crack the encryption protection used by the anonymizer service Tor. But no reports describing the agency's cryptanalytic successes and failures have been found in the Snowden collection to date. Interviews with current and former intelligence officials conducted over the past two months have revealed that since 9/11, NSA's computer scientists, electronic engineers, software programmers, and collection specialists have been remarkably inventive in finding new and innovative ways to circumvent the protections supposedly offered by encryption systems by compromising them through clandestine means. Among these clandestine means are CIA and FBI "black bag jobs," as well as secret efforts by the U.S. intelligence community to interdict the shipment of advanced encryption technology to America's enemies around the world, inserting "back doors" into commercially-available computer, communications and encryption technologies which allow NSA to covertly access these systems without the users knowing it. But the most sensitive of these clandestine techniques, and by far the most productive to date, is to covertly hack into targeted computers and copy the documents and message traffic stored on these machines before they are encrypted, a process known within NSA as "Endpoint" operations. Responsibility for conducting these Endpoint operations rests with the computer hackers of NSA's cyberespionage unit, the Office of Tailored Access Operations (TAO). According to sources familiar with the organization's operations, TAO has been enormously successful over the past 12 years in covertly inserting highly sophisticated spyware into the hard drives of over 80,000 computer systems around the world, although this number could be much higher. And according to the sources, these implants are designed in such a way that they cannot be detected by currently available commercial computer security software. It has been suggested to me by a reliable source that "this is not an accident," with the insinuation being that many of the biggest commercially-available computer security software systems made in the United States and overseas have been compromised by NSA, either covertly or with the knowledge and consent of the companies that manufacture these systems. Former agency personnel confirm that in innumerable instances these TAO implants have allowed NSA's analysts to copy and read all of the unencrypted documents stored on the targeted computer's hard drive, as well as copy every document and email message produced and/or transmitted by the machine. But more importantly, TAO has helped NSA's cryptanalysts solve several hundred foreign government and commercial encryption systems because these spyware implants, if properly inserted into the computer, can covertly alter its security software as well as copy the encryption system's technical parameters, especially the system's encryption algorithm and access passwords, in a way that cannot be detected. These implants can compromise the encryption systems used by not only the targeted computer, but also all other computer systems that it communicates with using encryption technology. According to confidential sources familiar with TAO's operations, many of NSA's cryptanalytic "success stories" against high-priority targets such as Russia and the People's Republic of China in recent years have been the direct result of TAO's cyberespionage efforts. For example, sources confirm that much of what the U.S. intelligence community knows about China's computer hacking efforts against targets in the United States, Europe, and Asia stems from TAO's intelligence collection efforts since 2005, when TAO reportedly achieved a major technical breakthrough against a Chinese target. But TAO doesn't just spy on America's rivals. In 2012, the group reportedly compromised the encryption system used by an important G8 country to transmit sensitive diplomatic communications via satellite to its embassies around the world. The same is true with a number of countries in the Middle East and South Asia, including Egypt, Syria, Iran, and Pakistan, although the details of these successes are not yet known. And finally, sources report that TAO has successfully compromised the privacy protection systems currently used on a range of 4G cell phones and hand-held devices, thanks in large part to help from a major American telecommunications company. There are high-profile targets that have proven resistant to TAO's cyberespionage efforts over the years, however. For example, TAO has reportedly had virtually no success penetrating North Korean government computer systems or networks because there are so few of them and they are heavily protected from access to the outside world. Over time, TAO has become increasingly accomplished at its mission, thanks in part to the high-level cooperation that it secretly receives from the "big three" American telecommunications companies (AT&T, Verizon, and Sprint), most of the large U.S.-based internet service providers, and many of the top computer security software manufacturers and consulting companies. According to a February 2012 budget document (.pdf) published earlier this year by ProPublica, these companies "Insert vulnerabilities into commercial encryption systems, IT systems, networks, and endpoint communications devices used by targets" on behalf of TAO. TAO is also very active in the global computer security industry marketplace, using the CIA, Defense Intelligence Agency, and State Department to help it keep close tabs on the latest computer security devices and software systems being developed around the world. And while details are lacking, informed sources report that TAO has been active in covertly buying up commercially available "hacker tools" or spyware software systems from individuals and companies in the United States and overseas, particularly in Western Europe, to help facilitate its ever-growing computer network exploitation efforts. The extreme sensitivity of TAO's collection efforts has required the NSA to take extraordinary steps to try to disguise its computer hacking activities. For instance, current and former intelligence sources confirm that TAO increasingly depends on clandestine techniques, such as commercial cover, to hide its activities. TAO uses an array of commercial business entities, some of them proprietary companies established specifically for this purpose, to try to hide its global computer hacking activities from computer security experts in a maze of interlocking computer servers and command-and-control systems located in the United States and overseas that have no discernible link to NSA or the U.S. government. These sources also say that TAO gets a lot of help from politically-motivated hackers, or "hacktivists," who unintentionally help NSA by providing ideas to improve TAO's collection efforts. (Exactly which hacktivists have been particularly helpful, these sources wouldn't say.) Working closely with NSA's computer security experts at the NSA/CSS Threat Operations Center, TAO personnel perform detailed forensic post-mortem studies of every major successful computer penetration operation around the world. Some of these are pulled off by criminal outfits, some by government-backed groups, others by political actors. In each case, the agency's personnel looks for new techniques or procedures that they can use to get inside computer systems around the world. There is no question that TAO's future looked incredibly bright before the first newspaper articles began appearing in the British and American press in June 2013 based on documents leaked by Snowden. Now, industry sources familiar with TAO say that the organization's future prospects have dimmed somewhat. A number of foreign-based computer systems and IT networks that formerly were major producers of intelligence information for TAO have over the past three months changed security procedures and encryption systems, routed traffic to more secure computer nodes or servers, erected new firewalls, or have gone offline altogether. According to recent press reports, the Russian government for a time reverted back to using manual typewriters rather than commit sensitive information to their computer systems. And a number of European countries and Brazil have begun shifting their most sensitive data and communications traffic to secure networks that they hope will be resistant to NSA's intrusive surveillance activities. But this is, I am sure, just the tip of the iceberg. I have no doubt that the damage to TAO's foreign intelligence collection capabilities and its ability to facilitate the solution of foreign encryption systems by NSA's cryptanalysts has been substantial. The big question that will determine TAO's future prospects is whether the damage done so far proves to be irreparable.

1 0