- cypherpunks - lists.cpunks.org

Trekkie finally got fired -- it's a good start
by Eugen Leitl 17 Oct '13

17 Oct '13

http://www.zerohedge.com/news/2013-10-16/keith-alexander-nsa-head-stepping-… Keith Alexander, NSA Head, Stepping Down Tyler Durden's pictureSubmitted by Tyler Durden on 10/16/2013 18:10 -0400 After eight years at the helm of "America's secret cyber army", NSA head Keith Alexander, has decided to spend more time with his family and less time with yours, and is stepping down. According to US officials, the director of the NSA and his deputy are expected to depart in coming months, in a move that almost certainly would not have happened without the involvement of America's most infamous whitsleblower currently self-exiled in Russia, Edward Snowden in a development which according to Reuters, "could give Obama a chance to reshape the eavesdropping agency." It is unclear what he would "reshape" it into: at last check the Stasi headquarters in Berlin did not have quite the capacity to house the Cray supercomputers needed to make sure that anyone and everyone caught selling stocks gets a lifetime audit guarantee from the IRS. We are confident, however, that with the surge in government-employed architects coming back to "work" from their 17 days paid vacation, someone will have an idea or two. >From Reuters: Army General Keith Alexander's eight-year tenure was rocked this year by revelations contained in documents leaked by former NSA contractor Edward Snowden about the agency's widespread scooping up of telephone, e-mail and social media data. Alexander has formalized plans to leave by next March or April, while his civilian deputy, John "Chris" Inglis, is due to retire by year's end, according to U.S. officials who spoke on condition of anonymity. It also wasn't clear who would replace the man who once upon a time made his office into a replica of the bridge of the Starship Enterprise, although there certainly are candidates. One leading candidate to replace Alexander is Vice Admiral Michael Rogers, currently commander of the U.S. Navy's 10th Fleet and U.S. Fleet Cyber Command, officials told Reuters. The 10th Fleet and Fleet Cyber Command both have their headquarters at Fort Meade, Maryland, between Washington and Baltimore. The NSA is also headquartered at Fort Meade. There has been no final decision on selecting Rogers to succeed Alexander, and other candidates may be considered, the officials said. More importantly, the question is whether with America's domestic epsionage and email address book collection efforts exposed for the entire world to see, courtesy of Edward Snowden, will Obama decide to engage in a strategic shift in policy, or merely double down and install RFID chips into every newborn American. While both men are leaving voluntarily, the dual vacancies give Obama an opportunity both to install new leadership following Snowden's revelations and to decide whether the NSA and Cyber Command should have separate leaders. Cyber Command, which has grown significantly in recent years, has the authority to engage in both defensive and offensive operations in cyberspace. Many NSA veterans argue that having the same person lead the spy agency and Cyber Command diminishes the emphasis on the NSA's work and its unique capabilities. Rogers has been the Navy's top cyber commander since September 2011. Prior to that, he was director of intelligence for the U.S. Joint Chiefs of Staff and for the U.S. Pacific Command. Rogers is "a good leader, very insightful and well thought of within the community," said a U.S. defense official who was not authorized to speak publicly on the matter. Rogers has worked hard to ensure that the Navy has sufficient sailors trained to take on added cyber responsibilities for U.S. Cyber Command, the official said. Sorry, we forgot to add "rhetorical" before question.

1 0

Re: [tor-talk] New paper : Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Paul Syverson <paul.syverson(a)nrl.navy.mil> ----- Date: Thu, 17 Oct 2013 06:56:41 -0400 From: Paul Syverson <paul.syverson(a)nrl.navy.mil> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] New paper : Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries Message-ID: <20131017105641.GE83425(a)buridan.fw5540.net> User-Agent: Mutt/1.5.17 (2007-11-01) Reply-To: tor-talk(a)lists.torproject.org On Thu, Oct 17, 2013 at 10:46:57AM +0200, Andreas Krey wrote: > On Wed, 16 Oct 2013 19:42:41 +0000, Joe Btfsplk wrote: > ... > > One thing jumps out, Tor doesn't know for sure who's running Guard or > > exit nodes - & can't unless they start doing (regular, repeated) > > extensive personal interviews, background checks, giving polygraph > > tests, injecting sodium pentathol to those wanting to run nodes. > > I think you slightly disregard who is actually interested in a > trustworthy tor network. What you describe makes the tor operators > a cabal, and the problem is that the ones who actually want to > trust tor (the users) are outside that. > > Besides, many attacks don't require to *run* the nodes, just to > monitor its traffic. And a TLA can do that without the honest > operator even suspecting. > Actually the work we did on this paper was as part of a larger program that has been our primary focus for the last several years: how can you secure communication over Tor against an adversary that can, e.g., own 30% of the nodes (or big chunk of guard and exit bandwidth) or large parts of the AS or other underlying network infrastructure. Our candidate is to leverage trust diversity in different parts of the network (e.g. trust based on who is running nodes on what hardware and what OS from what physical and network location, etc.) But this is tricky. One can't just use the most trusted parts of the network because this will probably indicate that this is statistically more likely to be communication from/to people that trust this part of the network. You need to get away from the idea of a single set of trust values for all users for the whole network. Different kinds of people will have different adversaries, which is just one factor to the diversity of trust. We've already got a few publications on this "More Anonymous Onion Routing Through Trust" by myself and Aaron Johnson and "Trust-based Anonymous Communication: Adversary Models and Routing Algorithms" by the two of us, plus Roger Dingledine and Nick Mathewson. You can find both on my homepage (syverson.org) The current paper under discussion came from the realization that we needed to have a much better handle on network models, tools and appropriate adversary models for the existing Tor network and usage in order to properly incorporate trust into routing for improved future design. HTH, Paul -- 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: [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 22:12:14 -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: <20131017021214.GA8443(a)thunk.org> User-Agent: Mutt/1.5.21 (2010-09-15) On Wed, Oct 16, 2013 at 05:10:00PM -0400, Jerry Leichter wrote: > 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. The answer is, "#1, the paper's claim that the Linux generator fails if the entropy sources are under the control of the adversary relies on the fact that it stops collecting entropy when it thinks the entropy pool is full, which is NOT TRUE, and #2, it's really, REALLY stupid to assume the adversary has complete control of the interrupt timing on your system." I think you have missed the first part. > 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. I'm not sure that's the best analogy, because there are known attack scenarios where someone might have some plaintext/ciphertext pairs and might be interested getting the key. I haven't seen an even half-way reasonable attack scenario where the attacker can control all of the entropy sources in the system --- not just know the interrupt timings, but to *control* the interrupt timings, in a very fine-grained way. (So it's not enough to just to know roughly when a packet gets sent to the machine, but to be able to send the packet such that you can control the exact value of the CPU counter, so you can fool the entropy estimator. And the attacker has to be able to do this not just for network interrupts, but also for disk, keynoard, and mouse interrupts, all at the same time. Yeaah.....) > (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.) That's only true if they have fairly privileged access to the hypervisor. And while it's barely possible to imagine scenarios where an adversary would have read access to hypervisor memory, but not write access, that is actually pretty far-fetched. Feel free to construct a scenario.... > 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. Um, if you read the paper, its claim that /dev/random is not robust by their definition relied fundamentally about the entropy estimator being "wrong" because the adversary could control the inputs to the entropy pool, and thus construct inputs that would fool the entropy estimator. So it feeds into the discussion in a rather fundamental way. In the Linux Pseudo Random Number Generator Revisited paper (http://eprint.iacr.org/2012/251.pdf) the authors sampled and analyzed the various real-life entropy sources, and found the entropy estimation to be pretty good, and if it erred, it erred on the side of convervatism, which is as designed. In case you were wondering, I'll consider this "good" academoc research --- not because I like the result, but because they actually carried out research instead of relying only on articially created attacks dressed up in the language of mathematical formalism. Formal proofs may be impressive, but it's nice if the formalism is actually tied to reality, instead of tenuously based on some fantastical assumptions, e.g., "The US Naval aircraft carrier is not robust against photon torpedoes". You can do lots of formal mathematics involving weapons yield to "prove" such a result, but it begs the question of whether photon torpedos exist in the real world. - Ted _______________________________________________ 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: [tor-talk] New paper : Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Joe Btfsplk <joebtfsplk(a)gmx.com> ----- Date: Wed, 16 Oct 2013 19:42:41 -0500 From: Joe Btfsplk <joebtfsplk(a)gmx.com> To: tor-talk(a)lists.torproject.org Subject: Re: [tor-talk] New paper : Users Get Routed: Traffic Correlation on Tor by Realistic Adversaries Message-ID: <525F3281.9030703(a)gmx.com> User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 Reply-To: tor-talk(a)lists.torproject.org On 10/16/2013 4:50 PM, Roger Dingledine wrote: > On Sun, Sep 01, 2013 at 10:10:56PM -0400, Roger Dingledine wrote: >> >> Yep. They're part of the Tor research community. I have plans for writing >> a blog post about the paper, to explain what it means, what it doesn't >> mean, what we should do about it, and what research questions remain >> open. > Here it is: > > https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-pa… > > --Roger I read the paper - good job. Some of it will be over the heads of some, but that's unavoidable unless make it 10+ pages, in newbie language, then few would read it all, so... I'm not bashing Tor here, so leave your pitchforks in the barn. Just asking questions, making observations that may / may not have an answer or even be useful. One thing jumps out, Tor doesn't know for sure who's running Guard or exit nodes - & can't unless they start doing (regular, repeated) extensive personal interviews, background checks, giving polygraph tests, injecting sodium pentathol to those wanting to run nodes. I guess more so for Guards. Since apparently now LEAs from (some) countries are teaming up, sharing info, etc., seems possible the problem of LEAs (or any adversaries) running a higher % of nodes could get worse, not better. If adversary nodes as a % of all nodes doesn't increase (new good guy nodes keeps up w/ increase of adversarial ones), then overall risk hasn't changed. But how can Tor (or any group) determine the risk if they have no reasonably reliable way to determine the REAL intention / identity of node operators (spies infiltrating Tor Network)? Governments, crooks have proven themselves VERY resourceful over decades, or 100's of yrs. The U.S., let alone other industrialized nations partnering together, has a lot more manpower, resources & money than Tor Project. I don't think we can out spend "them," for setting up nodes. How many full / part time programmers or "idea people" does Tor have (as good as they are) VS. one agency of one industrialized nation? Is there any way - in the future, that Tor could run a much larger % of nodes or at least, instead of constantly trying to figure how to "beat / drastically improve the odds" that an adversary won't accidentally control the entry / exit nodes on circuits? Perhaps a noble, but losing game, if gov'ts band together & decide Tor, or the entire internet, IS worth serious monitoring. Perhaps reasonable anonymity on a world wide party line is too ambitious? (Those that don't know what a "telephone party line" was, can "Startpage it." [stop saying "Google it"] :) What about somehow getting a better handle on who actually runs the nodes? With its current policies & design, Tor is in a very tough position to "ensure quality" (anonymity). Tor isn't supposed to see any real data on the network - for one, so they can't be forced to give anything up (again, noble), but that prevents some (a lot of?) capability for quality control. No company would / could handle its own security that way. It's a Catch 22 situation for Tor, because of legal threats that many gov'ts impose, that many corporations don't face. And if they had some REALLY secret stuff to send abroad, they'd fly it in their own jet. What about a COMPLETELY different approach, rather than trying to develop methods to "beat the odds," *ad infinitum,* against what COULD become an ever increasingly larger PERCENTAGE of gov't / adversary run nodes? Surely, it'd be worthwhile to look way down the road & see where Gov'ts / LEAs may be going w/ this & whether they can be "bested," by following the same course that Tor is on (even with improvements along the way)? I have no idea - I'm just saying, sometimes the only way businesses, technologies, gov'ts survive & thrive is to completely change course. For all of history, gov'ts have gone to GREAT lengths to spy on citizens & adversaries & have often done pretty well at it. Well liked corporations can often be as secretive as they want - they're "protecting corporate data & assets." Tor is looked at in part (*by gov'ts & LEAs*), as a tool for terrorists, criminals - of all sorts. They couldn't care less if honest people, whistle blowers swim near schools of criminals & terrorists, whether some will get caught in the same net. Maybe, like Corporations that get away w/ figurative murder, Tor Project should start contributing heavily to key political figures, to ensure they'll "be left alone?" :D You laugh, but that's exactly why big business, who by current STATUTES, break JUST AS MANY OR MORE laws, as Gov'ts / LEAs *ASSUME* that Tor users do? Big Business is left alone & entities like Tor are on the hit list. -- 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: [tor-dev] Attentive Otter: Usability issues with existing OTR clients
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from Aaron <aagbsn(a)torproject.org> ----- Date: Thu, 17 Oct 2013 09:35:14 +0000 From: Aaron <aagbsn(a)torproject.org> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] Attentive Otter: Usability issues with existing OTR clients Message-ID: <CAJLvQyHCMjuYDWcbcv_6VZemKy9qRPOOgMO3aGXDErvk6Jvb7Q(a)mail.gmail.com> Reply-To: tor-dev(a)lists.torproject.org On Thu, Oct 17, 2013 at 1:03 AM, Mike Perry <mikeperry(a)torproject.org>wrote: > Here's the major usability pain points I've run in to with various OTR > clients over the years. Feel free to chime in with any additional issues > you've noticed. > > > 1. The multiple client problem: If you have two devices online > simultaneously under the same account, they will fight and endlessly > renegotiate. > > This issue may be specific to OTRv2 only. Arlo pointed out that this > change in OTRv3 may solve a lot of these problems: > > "Both fragmented and unfragmented messages contain sender and recipient > instance tags. This avoids an issue on IM networks that always relay all > messages to all sessions of a client who is logged in multiple times. In > this situation, OTR clients can attempt to establish an OTR session > indefinitely if there are interleaving messages from each of the > sessions." > -- https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html > > We should be sure we use these features properly, and make sure the > js-ctypes wrappers are updated to support the new libotr v3 APIs with > these instance tags. The current js-ctypes wrapper may still be v2 only. > > If for some reason these tags in v3 can only be used if both parties > support v3, perhaps we can add some additional code to track OTR state > using XMPP resource/device info and tell the OTR lib underneath that > different > XMPP resources are actually different users, so that at least XMPP > accounts won't have this problem. > > > 2. Better TOFU support: We should track only one OTR key for a given > XMPP resource/device ID. > > Some people I communicate with are constantly rotating OTR keys for > security and other reasons. However, this doesn't help me any: I have > accumulated about 50 keys of unknown age and usage pattern in my OTR > fingerprint list for them, and I have no idea which ones have been > changed due to compromise, device loss, or simply due to reinstall. > Worse, I have no idea which keys should correspond to which XMPP > resources/devices. > +10. This is huge. As you point out, you get a "Unverified/Verified" when using OTR. Verifying fingerprints of anonymous chat is practically impossible -- every side channel I can think of (telephone, meeting in person, email - ha) either leaks the act of contacting, isn't practical or convenient, or requires some kind of Internet reputation. I'd bet that most OTR users don't verify fingerprints. TOFU is a must, along with a dialogue that explains in simple terms what is going on, with a way to dismiss the dialogue (e.g. by correctly answering a security question). Perhaps replacing "Unverified" with "In use for: x days" ? > > If a user changes the key for a given XMPP resource ID, we should expire > the previous key and loudly alert the user of the fact that the > resource's key has changed, and ask them if they want to replace the old > key with the new key. We should not simply accumulate more keys by > default, especially for the same XMPP resource/device, and especially > not for unverified keys. > I think you mean that the existing key is expired after the user has OK'd using the new key. The UI should not be something you can just click away or ignore; it should be slightly inconvenient, and perhaps bidirectional (the user whose key changed gets prompted as well). At the same time, we should allow a different OTR key for each unique > XMPP resource ID, and perhaps allow non-XMPP keys to accumulate at user > option. > I'd like the opposite -- I would like to be able to bind the nickname *to* the OTR key, but change the XMPP or IRC id, or to put it another way, be able to keep a persistent cryptographic identity but use whatever underlying transport or throwaway account is convenient. Admittedly it's not as good as doing away with centralized resources completely, and I think a Hidden Service transport would be very interesting. (And it looks like the Tor network load testing results are looking good ;-) ) > > > 3. "Unreadable encrypted message" errors should be visible only to > advanced users/in the error console, and the client should transparently > renegotiate and resend. > > It looks like OTR has an ERROR_START_AKE flag for this, but for some > reason, some states of OTR in Pidgin still cause me to get and send > these errors and miss messages though, usually if one client has crashed > or restarted without properly ending the conversation. We should try > extra hard to force key re-negotiation in these cases. > > We probably also want an auto-responder after the renegotiation that > informs the other party that N messages were missed (for clients that > don't support OTR's built-in notifications). > > > 4. OTR shouldn't get stuck in the "Finished" state when you end a > conversation. > Yeah, I've seen this one too. > > I've noticed in the past that OTR seemed to refuse to automatically > negotiate/re-negotiate if it is still "Finished" regardless of your > "Require/Force OTR" setting. This is just bad, and often causes > plaintext to leak. > > > 5. It should be impossible for our client to send a message in plaintext > by default, and the client should discourage counterparties from sending > more than one plaintext message. > > Perhaps related to issue 3, I've not had very good results with the > "Require OTR"/"Force OTR" options on many clients. > > It also seems like many people's clients will still send the first > message unencrypted (to get the handshake hint), and on all clients OTR > doesn't seem to try very hard to negotiate if an unencrypted message is > received. > > On our side, we should hold those messages and send only the handshake > initiation (ie our default OTR mode should be REQUIRE_ENCRYPTION). > I think it might be simpler to block input until the OTR handshake has completed. That is, the text input area is simply unavailable (in Force OTR mode). > We may also want to consider a plaintext auto-reply for when we receive > unencrypted messages. Something like "Please install and enable OTR > before sending further messages" as a separate message in *addition* to > attempting an OTR handshake. > > It might be better to not fingerprint the client that you are using. OTOH the pidgin-otr plugin does behave this way. > 6. The UI should have per-message encryption indicators (send and receive) > > For many clients, the UI is not clear which messages were sent > encrypted, especially if the OTR state has changed due to > autonegotiation or "Finishing". We should have per-message icons for > both sent and received messages that indicate encryption status for that > message in the chat scrollback window. > That could be a little cluttered; I'd suggest background tinting or only flagging the unencrypted messages with skulls and crossbones. > > > 7. Logging should be off by default when OTR is on. > I guess people like logging for some reason, and I'll admit that pidgins "History" mode really enables asynchronous chat. Rather than require you *turn off* OTR to get this feature, an alternative would be to require a passphrase and automatically expunge encrypted logs after a configurable period of time. And, unlike other clients, perhaps telling the conversation counterparty that logging is enabled (e.g. the opposite of gchat "OTR" notifications ) at the start of the session would provide informed consent. And: 8. Require (or at least allow) a passphrase to decrypt the OTR private key. Or, store the key on a hardware token. The number of arbitrary file read bugs in pidgin makes me cry... > > > > > -- > Mike Perry > > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > > _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- 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: [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