October 2013 - cypherpunks@lists.ogf.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: Thu, 17 Oct 2013 13:53:11 -0400 From: Jerry Leichter <leichter(a)lrw.com> To: Kent Borg <kentborg(a)borg.org> Cc: tytso(a)mit.edu, cryptography(a)metzdowd.com Subject: Re: [Cryptography] /dev/random is not robust Message-Id: <5D9D1764-5578-42A4-BBB1-4586B5F167D3(a)lrw.com> X-Mailer: Apple Mail (2.1510) On Oct 17, 2013, at 1:05 PM, Kent Borg <kentborg(a)borg.org> wrote: > But is this something that /dev/urandom might do better? Should blocking be added to /dev/urandom immediately after boot until some reasonable threshold has been reached at least once? Or on first boot are common distributions restoring a bad seed file and /dev/random can't tell? Arrgh, I am starting to think that the RNG is the wrong place to fix it. > > Should RNGs attempt to detect uninitialized states and refuse to run? One answer to this question appears in the FIPS standards for RNG's. At times, they've required a continuous on-line test of the numbers being generated, with automatic shutdown if the test fail. These requirements almost certainly came from the hardware background of the FIPS standards. For hardware, certain failure modes - stuck at 0/stuck at 1 are the most obvious; short cycles due to some internal oscillation may be another - are extremely common, and worth checking for. For software-based deterministic PRNG's, such tests are mainly irrelevant - code doesn't develop such failures in the field. As the FIPS standards were adjusted for a more software-based world, the requirement for on-line testing was dropped. Looking through some old messages on the subject here on the Cryptography list, I found one from Francois Grieu back in July of 2010: > The Smart Card industry uses True RNG a lot. There, a common line of > thought is to use: > - a hardware RNG, which raw output (perhaps biased) is directly > accessible for testing purposes (only), so that the software can check > it in depth at startup and from time to time to ascertain that it is at > least generating a fair amount of entropy > - followed by appropriate post-processing in hardware (so as to gather > entropy at all time), acting as a mixer/debiaser:; e.g. something LFSR-based > - followed by a crude software test (e.g. no bit stuck) > - optionally followed by software postprocessing (the subject is > debated; this software has to be proven to not include weakness, and the > hardware + crude software test is certified to eliminate such weakness, > so why bother, some say) > > There is a standard, known as AIS31, on evaluating True RNG, which > de-facto enforces the first three steps > <https://www.bsi.bund.de/cae/servlet/contentblob/478130/publicationFile/3027…> > which references > <https://www.bsi.bund.de/cae/servlet/contentblob/478152/publicationFile/3027…> More recently, David Johnston, who I gather was involved in the design of the Intel on-chip RNG, commented in a response to a question about malfunctions going undetected: > That's what BIST is for. It's a FIPS and SP800-90 requirement. Of course, with generators like the Linux /dev/random, we're in some intermediate state, with hardware components that could fail feeding data into software components. My own view on this is that there's no point in testing the output of a deterministic PRNG, but the moment you start getting information from the outside world, you should be validating it. You can never prove that a data stream is random, but you can cheaply spot some common kinds of deviation from randomness - and if you're in a position to "pay" more (in computation/memory) you can spot many others. You have no hope of spotting a sophisticated *attack*, and even spotting code bugs that destroy randomness can be hard, but it's hard to come up with an example of an actual real-world hardware failure that would slip through. So you might as well do the testing. -- 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

Re: [Cryptography] /dev/random has issues
by Eugen Leitl 17 Oct '13

17 Oct '13

----- Forwarded message from John Denker <jsd(a)av8n.com> ----- Date: Thu, 17 Oct 2013 09:12:48 -0700 From: John Denker <jsd(a)av8n.com> CC: Cryptography <cryptography(a)metzdowd.com> Subject: Re: [Cryptography] /dev/random has issues Message-ID: <52600C80.3050407(a)av8n.com> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 Here is an experiment you can do, if you have a Linux system: cat /proc/sys/kernel/random/entropy_avail I predict that it is likely to be a smallish number, less than 192 bits, not enough to cut a PGP key. This seems to conflict with the stated purpose of having /dev/random, and with the purpose of having buffers within the device. On 10/17/2013 06:08 AM, Theodore Ts'o wrote: > using a Yarrow-like approach, I find the current version of /dev/random to be partly yarrow-like and partly not. It is yarrow-like in the sense that it performs updates in batches, with a substantial minimum batch-size. It is non-yarrow-like in that it presents far too much load on the upstream source of entropy. ================= On 10/13/2013 05:03 PM, Jerry Leichter wrote: > Hundreds of eyeballs may have been on the Linux code, but we still > ended up fielding a system with a completely crippled RNG and not > noticing for months. I'm not at all convinced that hundreds of eyeballs have ever looked at the source code for Linux /dev/random. In any case, a small number of careful eyeballs would be far more valuable than a huge number of cursory eyeballs. Suppose we provide /dev/random with a good source of entropy, including (!) a reliable estimate of the amount of entropy (hint: turbid). Even then, it is not at all obvious that the current version of the Linux /dev/random is a good custodian of the entropy it is given. I noticed this when working on the upcoming new version of turbid. It contains a subsystem that feeds entropy into /dev/random. I didn't want to look at /dev/random at all, but eventually I had to, because I couldn't figure out a way to feed it entropy without huge amounts of waste. AFAICT that isn't possible in the current version, although this is a fixable problem. A non-exhaustive list of questions and issues -- some quite deep and some quite superficial -- can be found at http://www.av8n.com/turbid/paper/devrandom.htm I have a prototype ("alpha") version of random.c that addresses most of these issues. If there are any misunderstandings about what /dev/random is doing, it would be good to clear them up sooner rather than later. ===================================== A word about the article by Dodis et al. claiming that /dev/random is "not robust". IMHO that is a red herring. It raises issues that have little direct importance. For one thing, there is no consensus that their definition of "robust" is relevant in a practical engineering sense. Perhaps more importantly, we must object to the assertions about «how hard (or, perhaps, impossible?) it is to design a sound entropy estimation procedure». It is a truism in many fields, including sculpture as well as programming, that it is easy to do things wrong and hard to do things right. However, that does not mean that things /cannot/ be done right. In particular, it is definitely *not* impossible to implement an entropy estimator based on the second law of thermodynamics, which is far more reliable than several other assumptions that form the basis of modern cryptography. Such a thing requires effort and depth of understanding and attention to detail, but it can be done. Hint: turbid. The existence of unimportant issues should not blind us to more-important issues. _______________________________________________ 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

2 1

[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