- cypherpunks - lists.cpunks.org

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 17:10:00 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: Theodore Ts'o <tytso(a)mit.edu> Cc: Sandy Harris <sandyinchina(a)gmail.com>, Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] /dev/random is not robust Message-Id: <2CE9C56B-774E-4152-8A21-237337F9954F(a)lrw.com> X-Mailer: Apple Mail (2.1510) Can we separate the issue of actual issues in the Linux RNG from the responses to this paper? It's been a long time since I worked on an RNG, for a product that ran on systems that provided nothing like /dev/random; our Linux version mixed in /dev/random, and our Windows system mixed in whatever Windows calls its random number provider. I have no doubt that the Linux RNG is immensely better than the hack we were able to cobble together - not being in the kernel severely restricted our entropy sources. From what I've seen of the Linux RNG, it does a pretty good job. I'm not about to suggest any code changes, and frankly nothing in this paper suggests any either. Following its guidelines would produce an entirely new RNG, which absolutely *no one should trust* until it's been kicked around in the community for a while. My problem is *entirely* with some of the intemperate responses I've seen out there, which basically say "Oh, that's just some academic nonsense, pay no heed". I've seen nothing of that sort from you, Theodore Ts'o, personally; while you clearly have an emotional attachment to the work you've done - don't we all? - your responses are mainly technical in nature, pointing out places where the paper misunderstood what the current implementation does. However, you do let a bit of an attitude come through in remarks about "not caring about publishing papers". As I said, there is good and bad academic work, and not even all the good academic work is actually useful. As an example of good and useful academic work, I usually point to Phil Rogoway's papers. While the papers themselves are highly technical and get into a great deal of detail, what comes out at the end are simple designs that can be, and have been, implemented. If you implement one of Rogoway's designs, you know t here's a formal proof behind it. You don't need to actually understand the proof - others have reviewed it and it's almost certainly solid. Merge sort will run in O(n log n) for you whether you understand the theory or not. I see the paper as valuable for proposing strong security definitions for "PRNG's with input", showing that neither Barak and Halevi's algorithm nor the Linux RNG's algorithm attain those definitions, but suggesting an algorithm that does. The answer "well, yes, the Linux generator fails if its entropy sources are bad in a particular way, but we have entropy sources that aren't" misses the point. At one time, not so very long ago, no one knew how to build a cipher secure against a known-plaintext attack. Today, that's assumed. A defense of a modern cipher as "well, we won't let anyone see the plaintext" isn't good enough. (Even worse is the claim that "you can only see the state of the PRNG from root, and then there are other attacks". This isn't even true - a Linux system frozen into a VM can't prevent anyone from reading that state if they want it hard enough.) Just as they extended Barak and Halevi's definitions, others may well come along and "tune" theirs. That doesn't make theirs, or Barak and Halevi's, work "wrong"; it just makes them incomplete. Others will also eventually come along and produce better algorithms that attain the various definitions that the community comes to agree on. I'm not sure how the whole business of entropy estimation feeds into this. There are others who've criticized it as just guesswork. Frankly, they have a point. John Denker's work on Turbid provides a much more principled approach to the problem. Still, the Linux kernel has to work with what it has. Whether new, better, strong approaches will come along in the future is impossible to tell. If they do, I would hope those engineering Linux and other systems will have the humility to admit that the direction they've been going was, as it turns out, incorrect, and that they should start again from scratch. That's how science and engineering are supposed to work. Random numbers are way too important to allow the kinds of dismissive responses we've been seeing. -- 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

[guardian-dev] This Friday: Open Office Hours (via Hangout/IRC)
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Nathan of Guardian <nathan(a)guardianproject.info> ----- Date: Wed, 16 Oct 2013 16:15:01 -0400 From: Nathan of Guardian <nathan(a)guardianproject.info> To: Guardian Dev <guardian-dev(a)lists.mayfirst.org> Subject: [guardian-dev] This Friday: Open Office Hours (via Hangout/IRC) Message-ID: <525EF3C5.5020906(a)guardianproject.info> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 https://plus.google.com/events/cumq8tucoc31ap55iqdn7pq9abs Members of the Guardian Project will be hosting weekly public hangouts every Friday for the rest of year to answer questions about our apps (Orbot, Orweb, ChatSecure), building on our mobile security libraries (IOCipher, SQLCipher, NetCipher) and using services like OStel (including how to run your own secure phone service!). We will also be live in IRC on Freenode at #guardianproject as always for those of you who don't feel the need to be on camera. Sound fun? You betcha it will be. This will be the first even on Friday, so please come and join. https://guardianproject.info _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/eugen%40leitl.org You are subscribed as: eugen(a)leitl.org ----- 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

[hackerspaces] New effort to fully audit TrueCrypt raises $16, 000+ in a few short weeks
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from ITechGeek <itg(a)itechgeek.com> ----- Date: Thu, 17 Oct 2013 04:43:59 -0400 From: ITechGeek <itg(a)itechgeek.com> To: HacDC <blabber(a)hacdc.org>, HacDC <members(a)hacdc.org>, Hackerspaces General Discussion List <discuss(a)lists.hackerspaces.org>, Chatter <chatter(a)nova-labs.org> Subject: [hackerspaces] New effort to fully audit TrueCrypt raises $16, 000+ in a few short weeks Message-ID: <CAN2EnhCOKEqG+=sA1ZaXcSq=isAEseOHDHaZBYR4UmzeWmd5SQ(a)mail.gmail.com> Reply-To: Hackerspaces General Discussion List <discuss(a)lists.hackerspaces.org> http://arstechnica.com/security/2013/10/new-effort-to-fully-audit-truecrypt… ----------------------------------------------------------------------------------------------- -ITG (ITechGeek) ITG(a)ITechGeek.Com https://itg.nu/ GPG Keys: https://itg.nu/contact/gpg-key Preferred GPG Key: Fingerprint: AB46B7E363DA7E04ABFA57852AA9910A DCB1191A Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook: http://fb.me/Jbwa.Net _______________________________________________ Discuss mailing list Discuss(a)lists.hackerspaces.org http://lists.hackerspaces.org/mailman/listinfo/discuss ----- 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 Sean Lynch <seanl(a)literati.org> ----- Date: Wed, 16 Oct 2013 12:50:55 -0700 From: Sean Lynch <seanl(a)literati.org> To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> Subject: Re: [p2p-hackers] Distributed identity, chat, publishing, and sharing Message-ID: <87a9i9f10g.fsf(a)literati.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Reply-To: theory and practice of decentralized computer networks <p2p-hackers(a)lists.zooko.com> 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. 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. 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. -- Sean Lynch <seanl(a)literati.org> _______________________________________________ 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

Cryptographer Adi Shamir Prevented from Attending NSA History Conference
by Eugen Leitl 17 Oct '13

17 Oct '13

http://blogs.fas.org/secrecy/2013/10/shamir/ Cryptographer Adi Shamir Prevented from Attending NSA History Conference Categories: Science, Secrecy In this email message to colleagues, Israeli cryptographer Adi Shamir recounts the difficulties he faced in getting a visa to attend the 2013 Cryptologic History Symposium sponsored by the National Security Agency. Adi Shamir is the “S” in the RSA public-key algorithm and is “one of the finest cryptologists in the world today,” according to historian David Kahn. The NSA Symposium begins tomorrow. For the reasons described below, Dr. Shamir will not be there. From: Adi Shamir Date: October 15, 2013 12:16:28 AM EDT To: Subject: A personal apology The purpose of this email is to explain why I will not be able to attend the forthcoming meeting of the History of Cryptology conference, even though I submitted a paper which was formally accepted. As an active participant in the exciting developments in academic cryptography in the last 35 years, I thought that it would be a wonderful opportunity to meet all of you, but unfortunately the US bureaucracy has made this impossible. The story is too long to describe in detail, so I will only provide its main highlights here. I planned to visit the US for several months, in order to attend the Crypto 2013 conference, the History of Cryptology conference, and to visit several universities and research institutes in between in order to meet colleagues and give scientific lectures. To do all of these, I needed a new J1 visa, and I filed the visa application at the beginning of June, two and a half months before my planned departure to the Crypto conference in mid August. I applied so early since it was really important for me to attend the Crypto conference – I was one of the founders of this flagship annual academic event (I actually gave the opening talk in the first session of the first meeting of this conference in 1981) and I did my best to attend all its meetings in the last 32 years. To make a long story short, after applying some pressure and pulling a lot of strings, I finally got the visa stamped in my passport on September 30-th, exactly four months after filing my application, and way beyond the requested start date of my visit. I was lucky in some sense, since on the next day the US government went into shutdown, and I have no idea how this could have affected my case. Needless to say, the long uncertainty had put all my travel plans (flights, accomodations, lecture commitments, etc) into total disarray. It turns out that I am not alone, and many foreign scientists are now facing the same situation. Here is what the president of the Weizmann Institute of Science (where I work in Israel) wrote in July 2013 to the US Ambassador in Israel: “I’m allowing myself to write you again, on the same topic, and related to the major difficulties the scientists of the Weizmann Institute of Science are experiencing in order to get Visa to the US. In my humble opinion, we are heading toward a disaster, and I have heard many people, among them our top scientists, saying that they are not willing anymore to visit the US, and collaborate with American scientists, because of the difficulties. It is clear that scientists have been singled out, since I hear that other ‘simple citizen’, do get their visa in a short time.” Even the president of the US National Academy of Science (of which I am a member) tried to intervene, without results. He was very sympathetic, writing to me at some stage: “Dear Professor Shamir I have been hoping, day by day, that your visa had come through. It is very disappointing to receive your latest report. We continue to try by seeking extra attention from the U. S. Department of State, which has the sole authority in these matters. As you know, the officers of the Department of State in embassies around the world also have much authority. I am personally very sympathetic and hopeful that your efforts and patience will still yield results but also realize that this episode has been very trying. We hope to hear of a last-minute success. Yours sincerely, Ralph J. Cicerone” What does all of this have to do with the History of Cryptology conference? In January 2013 I submitted a paper titled “The Cryptology of John Nash From a Modern Perspective” to the conference, and a short time afterwards I was told by the organizers that it was accepted. In July 2013 I told the NSA-affiliated conference organizers that I was having some problems in getting my visa, and gently asked whether they could do something about it. Always eager to help, the NSA people leaped into action, and immediately sent me a short email written with a lot of tact: “The trouble you are having is regrettable…Sorry you won’t be able to come to our conference. We have submitted our program and did not include you on it.” I must admit that in my 35 years of attending many conferences, it had never happened to me that an accepted paper of mine was yanked out from the official program in such a unilateral way. However, since I never try to go to places where I do not feel wanted, I decided to inform MIT that a window had become available in my busy schedule. They immediately invited me to visit them on October 17 and 18, and to give a major lecture during my visit. Naturally, I accepted their gracious invitation. The final twist in this saga happened a few days ago, when out of the blue I was suddenly reinvited by the conference organizers to attend the event and to present my paper. However, this is too late now, since I am already fully committed to my visit to MIT. So what is the bottom line of this whole unhappy episode? Clearly, no one in the US is trying to see the big picture, and the heavy handed visa bureaucracy you have created seems to be collapsing under its own weight. This is not a security issue – I have been to the US close to a hundred times so far (including some multi-year visits), and had never overstayed my visas. In addition, the number of terrorists among the members of the US National Academy of Science is rather small. As a friend of the US I am deeply worried that if you continue to delay visas in such a way, the only thing you will achieve is to alienate many world-famous foreign scientists, forcing them to increase their cooperation with European or Chinese scientists whose countries roll the red carpet for such visits. Is this really in the US best interest? Best personal wishes, and apologies for not being able to meet you in person, Adi Shamir

1 0

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