- cypherpunks - lists.cpunks.org

[cryptography] Vernam, Mauborgne, Friedman: The One-Time Pad and the Index of Coincidence
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from John Young <jya(a)pipeline.com> ----- Date: Thu, 17 Oct 2013 16:22:35 -0400 From: John Young <jya(a)pipeline.com> To: cryptography(a)randombit.net, cypherpunks(a)cpunks.org, cryptome(a)freelists.org Subject: [cryptography] Vernam, Mauborgne, Friedman: The One-Time Pad and the Index of Coincidence X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Message-ID: <E1VWu4z-0004yQ-3B(a)elasmtp-junco.atl.sa.earthlink.net> Steven Bellovin Talk at NSA History Conference today: Vernam, Mauborgne, Friedman: The One-Time Pad and the Index of Coincidence <https://www.cs.columbia.edu/%7Esmb/talks/VernamMauborgneFriedman.pdf>https://www.cs.columbia.edu/~smb/talks/VernamMauborgneFriedman.pdf _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5

1 0

Vernam, Mauborgne, Friedman: The One-Time Pad and the Index of Coincidence
by John Young 17 Oct '13

17 Oct '13

Steven Bellovin Talk at NSA History Conference today: Vernam, Mauborgne, Friedman: The One-Time Pad and the Index of Coincidence <https://www.cs.columbia.edu/%7Esmb/talks/VernamMauborgneFriedman.pdf>https://www.cs.columbia.edu/~smb/talks/VernamMauborgneFriedman.pdf

1 0

beware of potential Lavabit honeypot
by Eugen Leitl 17 Oct '13

17 Oct '13

See thread on http://www.reddit.com/r/privacy/comments/1okv6c/fbinsa_have_set_up_a_honeyp…

1 0

NSA's key role in targeted killings
by Eugen Leitl 17 Oct '13

17 Oct '13

http://www.washingtonpost.com/world/national-security/documents-reveal-nsas… Documents reveal NSA’s extensive involvement in targeted killing program Video: In June, President Obama said the NSA’s programs “help us prevent terrorist attacks.” By Greg Miller, Julie Tate and Barton Gellman, Thursday, October 17, 2:07 AM E-mail the writers It was an innocuous e-mail, one of millions sent every day by spouses with updates on the situation at home. But this one was of particular interest to the National Security Agency and contained clues that put the sender’s husband in the crosshairs of a CIA drone. Days later, Hassan Ghul — an associate of Osama bin Laden who provided a critical piece of intelligence that helped the CIA find the al-Qaeda leader — was killed by a drone strike in Pakistan’s tribal belt. The U.S. government has never publicly acknowledged killing Ghul. But documents provided to The Washington Post by former NSA contractor Edward Snowden confirm his demise in October 2012 and reveal the agency’s extensive involvement in the targeted killing program that has served as a centerpiece of President Obama’s counterterrorism strategy. An al-Qaeda operative who had a knack for surfacing at dramatic moments in the post-Sept. 11 story line, Ghul was an emissary to Iraq for the terrorist group at the height of that war. He was captured in 2004 and helped expose bin Laden’s courier network before spending two years at a secret CIA prison. Then, in 2006, the United States delivered him to his native Pakistan, where he was released and returned to the al-Qaeda fold. But beyond filling in gaps about Ghul, the documents provide the most detailed account of the intricate collaboration between the CIA and the NSA in the drone campaign. The Post is withholding many details about those missions, at the request of U.S. intelligence officials who cited potential damage to ongoing operations and national security. The NSA is “focused on discovering and developing intelligence about valid foreign intelligence targets,” an NSA spokeswoman said in a statement provided to The Post on Wednesday, adding that the agency’s operations “protect the nation and its interests from threats such as terrorism and the proliferation of weapons of mass destruction.” In the search for targets, the NSA has draped a surveillance blanket over dozens of square miles of northwest Pakistan. In Ghul’s case, the agency deployed an arsenal of cyber-espionage tools, secretly seizing control of laptops, siphoning audio files and other messages, and tracking radio transmissions to determine where Ghul might “bed down.” The e-mail from Ghul’s wife “about her current living conditions” contained enough detail to confirm the coordinates of that household, according to a document summarizing the mission. “This information enabled a capture/kill operation against an individual believed to be Hassan Ghul on October 1,” it said. The file is part of a collection of records in the Snowden trove that make clear that the drone campaign — often depicted as the CIA’s exclusive domain — relies heavily on the NSA’s ability to vacuum up enormous quantities of e-mail, phone calls and other fragments of signals intelligence, or SIGINT. To handle the expanding workload, the NSA created a secret unit known as the Counter-Terrorism Mission Aligned Cell, or CT MAC, to concentrate the agency’s vast resources on hard-to-find terrorism targets. The unit spent a year tracking Ghul and his courier network, tunneling into an array of systems and devices, before he was killed. Without those penetrations, the document concluded, “this opportunity would not have been possible.” At a time when the NSA is facing intense criticism for gathering data on Americans, the drone files may bolster the agency’s case that its resources are focused on fighting terrorism and supporting U.S. operations overseas. “Ours is a noble cause,” NSA Director Keith B. Alexander said during a public event last month. “Our job is to defend this nation and to protect our civil liberties and privacy.” The documents do not explain how the Ghul e-mail was obtained or whether it was intercepted using legal authorities that have emerged as a source of controversy in recent months and enable the NSA to compel technology giants including Microsoft and Google to turn over information about their users. Nor is there a reference to another NSA program facing scrutiny after Snowden’s leaks, its metadata collection of numbers dialed by nearly every person in the United States. To the contrary, the records indicate that the agency depends heavily on highly targeted network penetrations to gather information that wouldn’t otherwise be trapped in surveillance nets that it has set at key Internet gateways. The new documents are self-congratulatory in tone, drafted to tout the NSA’s counterterrorism capabilities. One is titled “CT MAC Hassan Gul Success.” The files make no mention of other agencies’ roles in a drone program that escalated dramatically in 2009 and 2010 before tapering off in recent years. Even so, former CIA officials said the files are an accurate reflection of the NSA’s contribution to finding targets in a campaign that has killed more than 3,000 people, including thousands of alleged militants and hundreds of civilians, in Pakistan, according to independent surveys. The officials said the agency has assigned senior analysts to the CIA’s Counterterrorism Center, and deployed others to work alongside CIA counterparts at almost every major U.S. embassy or military base overseas. “NSA threw the kitchen sink at the FATA,” said a former U.S. intelligence official with experience in Afghanistan and Pakistan, referring to the Federally Administered Tribal Areas, the region in northwest Pakistan where al-Qaeda’s leadership is based. NSA employees rarely ventured beyond the security gates of the U.S. Embassy in Islamabad, officials said. Surveillance operations that required placing a device or sensor near an al-Qaeda compound were handled by the CIA’s Information Operations Center, which specializes in high-tech devices and “close-in” surveillance work. “But if you wanted huge coverage of the FATA, NSA had 10 times the manpower, 20 times the budget and 100 times the brainpower,” the former intelligence official said, comparing the surveillance resources of the NSA to the smaller capabilities of the agency's IOC. The two agencies are the largest in the U.S. intelligence community, with budgets last year of $14.7 billion for the CIA and $10.8 billion for the NSA. “We provided the map,” the former official said, “and they just filled in the pieces.” In broad terms, the NSA relies on increasingly sophisticated versions of online attacks that are well-known among security experts. Many rely on software implants developed by the agency’s Tailored Access Operations division with code-names such as UNITEDRAKE and VALIDATOR. In other cases, the agency runs “man-in-the-middle” attacks in which it positions itself unnoticed midstream between computers communicating with one another, diverting files for real-time alerts and longer-term analysis in data repositories. Through these and other tactics, the NSA is able to extract vast quantities of digital information, including audio files, imagery and keystroke logs. The operations amount to silent raids on suspected safe houses and often are carried out by experts sitting behind desks thousands of miles from their targets. The reach of the NSA’s Tailored Access Operations division extends far beyond Pakistan. Other documents describe efforts to tunnel into systems used by al-Qaeda affiliates in Yemen and Africa, each breach exposing other corridors. An operation against a suspected facilitator for al-Qaeda’s branch in Yemen led to a trove of files that could be used to “help NSA map out the movement of terrorists and aspiring extremists between Yemen, Syria, Turkey, Egypt, Libya and Iran,” according to the documents. “This may enable NSA to better flag the movement of these individuals” to allied security services that “can put individuals on no-fly lists or monitor them once in country.” A single penetration yielded 90 encrypted al-Qaeda documents, 16 encryption keys, 30 unencrypted messages as well as “thousands” of chat logs, according to an inventory described in one of the Snowden documents. The operations are so easy, in some cases, that the NSA is able to start downloading data in less time than it takes the targeted machine to boot up. Last year, a user account on a social media Web site provided an instant portal to an al-Qaeda operative’s hard drive. “Within minutes, we successfully exploited the target,” the document said. The hunt for Ghul followed a more elaborate path. Ghul, who is listed in other documents as Mustafa Haji Muhammad Khan, had surfaced on U.S. radar as early as 2003, when an al-Qaeda detainee disclosed that Ghul escorted one of the intended hijackers to a Pakistani safe house a year before the Sept. 11, 2001, attacks. A trusted facilitator and courier, Ghul was dispatched to Iraq in 2003 to deliver a message to Abu Musab al-Zarqawi, the al-Qaeda firebrand who angered the network’s leaders in Pakistan by launching attacks that often slaughtered innocent Muslims. When Ghul made another attempt to enter Iraq in 2004, he was detained by Kurdish authorities in an operation directed by the CIA. Almost immediately, Ghul provided a piece of intelligence that would prove more consequential than he may have anticipated: He disclosed that bin Laden relied on a trusted courier known as al-Kuwaiti. The ripples from that revelation wouldn’t subside for years. The CIA went on to determine the true identity of al-Kuwaiti and followed him to a heavily fortified compound in Abbottabad, Pakistan, where bin Laden was killed in 2011. Because of the courier tip, Ghul became an unwitting figure in the contentious debate over CIA interrogation measures. He was held at a CIA black site in Eastern Europe, according to declassified Justice Department memos, where he was slapped and subjected to stress positions and sleep deprivation to break his will. Defenders of the interrogation program have cited Ghul’s courier disclosure as evidence that the agency’s interrogation program was crucial to getting bin Laden. But others, including former CIA operatives directly involved in Ghul’s case, said that he identified the courier while he was being interrogated by Kurdish authorities, who posed questions scripted by CIA analysts in the background. The debate resurfaced amid the release of the movie “Zero Dark Thirty” last year, in which a detainee’s slip after a brutal interrogation sequence is depicted as a breakthrough in the bin Laden hunt. Ghul’s case also has been explored in detail in a 6,000-page investigation of the CIA interrogation program by the Senate Intelligence Committee that has yet to be released. Sen. Dianne Feinstein (D-Calif.), the chairman of the panel, sought to settle the Ghul debate in a statement last year that alluded to his role but didn’t mention him by name. “The CIA detainee who provided the most significant information about the courier provided the information prior to being subjected to coercive interrogation techniques,” Feinstein said in the statement, which was signed by Sen. Carl Levin (D-Mich.). The George W. Bush administration’s decision to close the secret CIA prisons in 2006 set off a scramble to place prisoners whom the agency did not regard as dangerous or valuable enough to transfer to Guantanamo Bay. Ghul was not among the original 14 high-value CIA detainees sent to the U.S. installation in Cuba. Instead, he was turned over to the CIA’s counterpart in Pakistan, with ostensible assurances that he would remain in custody. A year later, Ghul was released. There was no public explanation from Pakistani authorities. CIA officials have noted that Ghul had ties to Lashkar-e-Taiba, a militant group supported by Pakistan’s intelligence service. By 2007, he had returned to al-Qaeda’s stronghold in Waziristan. In 2011, the Treasury Department named Ghul a target of U.S. counterterrorism sanctions. Since his release, the department said, he had helped al-Qaeda reestablish logistics networks, enabling al-Qaeda to move people and money in and out of the country. The NSA document described Ghul as al-Qaeda’s chief of military operations and detailed a broad surveillance effort to find him. “The most critical piece” came with a discovery that “provided a vector” for compounds used by Ghul, the document said. After months of investigation, and surveillance by CIA drones, the e-mail from his wife erased any remaining doubt. Even after Ghul was killed in Mir Ali, the NSA’s role in the drone strike wasn’t done. Although the attack was aimed at “an individual believed to be” the correct target, the outcome wasn’t certain until later when, “through SIGINT, it was confirmed that Hassan Ghul was in fact killed.”

1 0

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