July 2018 - cypherpunks-legacy

Re: [tahoe-dev] LAFS Weekly Dev Hangout notes, 2012-12-06
by Paul Rabahy 06 Jul '18

06 Jul '18

First off, let me say that I enjoyed listening in to the hangout even though I couldn't participate. For the last year or 2 I have been thinking about building a distributed, untrusted storage system. When I found Tahoe-lafs, I was ecstatic that it had already implemented about 90% of the ideas that I had thought of and that it sounds like the remaining 10% are being worked on. I have some comments on Zooko's Proof-of-Retrievability paper. 1. Great job writing this. It was very easy to read and get up to speed without having to read 10 other whitepapers first to understand the basics. (I have some background in cryptography/secure computing from college) 2. I completely agree with the 3 levels of bad behavior (Greed, Malice, and Adaptive Malice). In addition, I believe there should be a fourth level which I will call "Accidental Greed". In this case, the sever stores the data, responds to all requests properly, but one day fails (either a POR or GetData request) for some unknown reason. This server will acknowledge their mistake and attempt to reverse it once they are notified (restore backups, patch bug, etc.). 2a. For POR, Zooko nailed this. We don't have to care about "Accidental Greed" at the protocol level because if we cover our-self for Malice or Adaptive Malice we already have a solution. 3. I am convinced that to prevent Malice or Adaptive Malice, there cannot be a difference between running a POR or GetData. If there is either type of attacker could respond correctly to the POR but incorrectly to the GetData. 3a. For my use cases I feel that having POR and GetData can have different traffic patterns and not affect my experience as a customer. I realize that will introduce a gap in the protocol so that Adaptive Malice could defeat the POR. I would like for POR to cover me 90% of the time, but occasionally I will actually download a file and will be able to catch the Adaptive Malice server at that point. (This might seem like a contradiction, but Tahoe already has the enormously powerful feature of erasure coding to protect me from an occasional malicious server even if POR fails.) 4. Unfortunately Zooko lost me in Part 2b and 3. I understand the trade-off between "(a) reduced performance for downloads, and/or (b) increased bandwidth usage for verification", but I was never able to understand how Tahoe is supposed to be convinced that a share is retrievable without even contacting the server containing the share. 4a. Several times during the hangout, it was mentioned that increasing N and K would help POR to work better. I don't follow that argument. I agree that setting N higher increases the retrievability of a file (because it can withstand more malicious servers), but I don't see how increasing either of these will help me single out the malicious server. 5. I need to do more reading on the current Tahoe verify system, but I don't understand how Tahoe can verify a file using B Bandwidth where B is less than F Filesize. 5a. Using the Tahoe defaults (K = 3, N = 10) and assuming that F = 1(MB) it will take 3.33(MB) to store all ten shares. Each share will take .333(MB) to store. To verify the file, wouldn't you have to retrieve at least K shares therefor B would equal .333(MB) * 3(K) = 1MB(F). To me, it seems we didn't save any bandwidth. 5b. (Ah, just thought of this as I was writing). Does Tahoe maintain some sort of tree/share based hash so that it can verify individual shares or parts of a share without verifying the entire file? If so, I can see the bandwidth savings. 6. I agree that TOR/distributed verification could help in the case of an Adaptive Malicious server, but until I have a clearer understanding of my points 5 and 6, I'm not sure if this description of POR will be have a benefit for my use case. Hopefully these points make sense. Let me know if I made anything confusing. PRabahy On Thu, Dec 6, 2012 at 3:42 PM, Zooko Wilcox-O'Hearn <zooko(a)zooko.com>wrote: > In attendance: Brian, David-Sarah, Zooko (scribe), Andrew, PRabahy (silent) > > The meeting started about 10 minutes late and ran more than 30 minutes > past its scheduled stop-time. (Because we were too engaged to stop at > the stop-time since we were sorting out the question of whether > Zooko's "Strong Proof-of-Retrievability" concept was inherently as > inefficient as simply downloading the whole file.) > > Caveat Lector! I might have forgotten some stuff. I haven't taken the > time to add explanations for most of what follows. My own biases shine > through willy nilly. > > > * The LAFS-PoR.rst text file was cleverly hidden behind an obstacle course. > > * 'Ephemeral Elliptic Curve Diffie-Hellmanb= My friend Zooko excels at > redefining "What 'everyone' or what 'no-one' uses."' > > * leasedb+cloud-backend > * LeastAuthority.com has at long last delivered Milestone 3 to > DARPA. Milestone 1 was a design document Milestone 2 was Cloud/S3 > backend, and Milestone 3 was leasedb. > * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1818 / > https://github.com/davidsarah/tahoe-lafs/tree/1818-leasedb is the > implementation of leasedb against trunk (disk backend) > * https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1819 / > https://github.com/davidsarah/tahoe-lafs/tree/1819-cloud-merge is the > merge of that with the cloud backend > * The 1819-cloud-merge branch passes all unit tests, and passes > manual testing by David-Sarah. It is currently being evaluated on > behalf of DARPA by their contractors, BITSYS. > * next steps: > * Keep 1818-leasedb and 1819-cloud-merge out of Tahoe-LAFS v1.10. > * Let Brian review them. > * David-Sarah is still re-recording the patch series for > 1819-cloud-merge. > * Zooko is still code-reviewing the patches. > * Check for the transition experience b what happens the first > time you upgrade, for example. > * There is at least one incomplete detail about transition: > starter leases don't get added (there isn't a ticket for this b we > should open one). > * Zooko and David-Sarah want to implement #1834 and related > tickets b not necessarily before we land it on trunk, but before we > release 1.11. Or we could do it on the branch before we land it on > trunk. > > * Tahoe-LAFS v1.10 > * Let's package up what we have currently on trunk (plus, Zooko > added to these notes after the meeting, possibly a few other good > patches that are basically already done, are very non-disruptive b > such as documentation-only patches b and/or have forward-compatibility > implications, such as #1240, #1802, #1789, #1477, #901, #1539, #1643, > #1842, and #1679). > * Everyone review pending tickets! > https://tahoe-lafs.org/trac/tahoe-lafs/milestone/1.10.0 > * The next Weekly Dev Hangout will be about Tahoe-LAFS v1.10 > * goal: get trunk to meet our desires for Tahoe-LAFS v1.10, release > from trunk > * Brian wants to fix #1767, which has forward-compatibility > implications. > > * tarcieri's new HTML > * not for 1.10 > * It changes only the front page and so the other pages are > inconsistent with the new front page. > * But commit it to a branch ASAP and demonstrate to tarcieri that > we're serious about merging it to trunk as soon as it is complete. > > * Proof-of-Retrievability > * Zooko has written a rough draft of a tahoe-dev post/science > paper, arguing that real "Strong" Proof-of-Retrievability is possible, > that the current exemplars in the crypto literature fail to provide > Strong Proofs-of-Retrievability, and that Tahoe-LAFS combined with Tor > would make a nice basis on which to build a Strong > Proof-of-Retrievability, and that if it did, it would be a practical > censorship-resistance tool. > * Brian posed some good challenges in practical terms about the > performance and bandwidth costs. > * The key difference that makes this new concept of > Proof-of-Retrievability different and better than previous attempts is > that it uses multiple storage servers (which are hopefully not > colluding with one another), and erasure-coding in order to keep total > upload and storage costs fixed even while scaling a single file, > horizontally, to a large number of storage servers. > * That's also the key to answering Brian's challenge b that sort of > spreading across storage servers alllows one to gain verification > assurance b *even* against Adaptive Malicious Storage Servers b at a > fraction of the aggregate bandwidth cost of a full download. If there > were only a single storage server then Juels-2009 and > Brian-in-this-meeting would be right that no efficient Strong PoR is > possible. > * Next steps: Zooko needs to rewrite the second half of the current > document to emphasize these insights gained from this meeting and to > streamline it. Several experts have volunteered to review it already. > Then: post it to tahoe-dev? > * David-Sarah has some idea that Brian and Zooko don't quite get > about improving the quantitative advantage to the defender by > increasing erasure coding parameters and storing multiple shares per > server. > * Let's get drunk and argue about whether God can see into the future. > _______________________________________________ > tahoe-dev mailing list > tahoe-dev(a)tahoe-lafs.org > https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev > _______________________________________________ tahoe-dev mailing list tahoe-dev(a)tahoe-lafs.org https://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [p2p-hackers] Re: Memory and reputation calculation
by Paul Campbell 06 Jul '18

06 Jul '18

With regards to the history function, I recall seeing a paper (no idea where or what the title was) that looked at it a different way. The concern is that in a P2P environment, there's no central assumed tamper-proof central server. One must rely on the peers themselves for history. It would be relatively easy for a peer to simply erase and ignore bad history, or for peers to be able to collude to report false history, unless one of two things happens: 1. The vector/group concept of Advogato among others prevents collusion simply because there are no multple paths...the false history shows up as a self-referential structure and not as a web of trust links. The group/vector concept searches for multiple disjoint paths of trust, which lessens or destroys collusion. 2. That the history passed on by a peer should be serialized in such a way that it is tamper-proof. That is, the client can't selectively delete events from the history. For instance, a one-way accumulator-type function intertwined into the data performs the protection. It doesn't circumvent the possibility of a client simply deleting the last few events in the history (and nothing is going to stop a client from doing a snapshot to achieve this), but it at least makes such selective editting an all-or-nothing function. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] Taking Spying to Higher Level, Agencies Look for More Ways to Mine Data,By JOHN MARKOFF
by Dave Farber 06 Jul '18

06 Jul '18

The New York Times February 25, 2006 Taking Spying to Higher Level, Agencies Look for More Ways to Mine Data By JOHN MARKOFF PALO ALTO, Calif., Feb. 23 b A small group of National Security Agency officials slipped into Silicon Valley on one of the agency's periodic technology shopping expeditions this month. On the wish list, according to several venture capitalists who met with the officials, were an array of technologies that underlie the fierce debate over the Bush administration's anti-terrorist eavesdropping program: computerized systems that reveal connections between seemingly innocuous and unrelated pieces of information. The tools they were looking for are new, but their application would fall under the well-established practice of data mining: using mathematical and statistical techniques to scan for hidden relationships in streams of digital data or large databases. Supercomputer companies looking for commercial markets have used the practice for decades. Now intelligence agencies, hardly newcomers to data mining, are using new technologies to take the practice to another level. But by fundamentally changing the nature of surveillance, high-tech data mining raises privacy concerns that are only beginning to be debated widely. That is because to find illicit activities it is necessary to turn loose software sentinels to examine all digital behavior whether it is innocent or not. "The theory is that the automated tool that is conducting the search is not violating the law," said Mark D. Rasch, the former head of computer-crime investigations for the Justice Department and now the senior vice president of Solutionary, a computer security company. But "anytime a tool or a human is looking at the content of your communication, it invades your privacy." When asked for comment about the meetings in Silicon Valley, Jane Hudgins, a National Security Agency spokeswoman, said, "We have no information to provide." Data mining is already being used in a diverse array of commercial applications b whether by credit card companies detecting and stopping fraud as it happens, or by insurance companies that predict health risks. As a result, millions of Americans have become enmeshed in a vast and growing data web that is constantly being examined by a legion of Internet-era software snoops. Technology industry executives and government officials said that the intelligence agency systems take such techniques further, applying software analysis tools now routinely used by law enforcement agencies to identify criminal activities and political terrorist organizations that would otherwise be missed by human eavesdroppers. One such tool is Analyst's Notebook, a crime investigation "spreadsheet" and visualization tool developed by i2 Inc., a software firm based in McLean, Va. The software, which ranges in price from as little as $3,000 for a sheriff's department to millions of dollars for a large government agency like the Federal Bureau of Investigation, allows investigators to organize and view telephone and financial transaction records. It was used in 2001 by Joyce Knowlton, an investigator at the Stillwater State Correctional Facility in Minnesota, to detect a prison drug-smuggling ring that ultimately implicated 30 offenders who were linked to Supreme White Power, a gang active in the prison. Ms. Knowlton began her investigation by importing telephone call records into her software and was immediately led to a pattern of calls between prisoners and a recent parolee. She overlaid the calling data with records of prisoners' financial accounts, and based on patterns that emerged, she began monitoring phone calls of particular inmates. That led her to coded messages being exchanged in the calls that revealed that seemingly innocuous wood blocks were being used to smuggle drugs into the prison. "Once we added the money and saw how it was flowing from addresses that were connected to phone numbers, it created a very clear picture of the smuggling ring," she said. Privacy, of course, is hardly an expectation for prisoners. And credit card customers and insurance policyholders give up a certain amount of privacy to the issuers and carriers. It is the power of such software tools applied to broad, covert governmental uses that has led to the deepening controversy over data mining. In the wake of 9/11, the potential for mining immense databases of digital information gave rise to a program called Total Information Awareness, developed by Adm. John M. Poindexter, the former national security adviser, while he was a program manager at the Defense Advanced Research Projects Agency. Although Congress abruptly canceled the program in October 2003, the legislation provided a specific exemption for "processing, analysis and collaboration tools for counterterrorism foreign intelligence." At the time, Admiral Poindexter, who declined to be interviewed for this article because he said he had knowledge of current classified intelligence activities, argued that his program had achieved a tenfold increase in the speed of the searching databases for foreign threats. While agreeing that data mining has a tremendous power for fighting a new kind of warfare, John Arquilla, a professor of defense analysis at the Naval Postgraduate School in Monterey, Calif., said that intelligence agencies had missed an opportunity by misapplying the technologies. "In many respects, we're fighting the last intelligence war," Mr. Arquilla said. "We have not pursued data mining in the way we should." Mr. Arquilla, who was a consultant on Admiral Poindexter's Total Information Awareness project, said that the $40 billion spent each year by intelligence agencies had failed to exploit the power of data mining in correlating information readily available from public sources, like monitoring Internet chat rooms used by Al Qaeda. Instead, he said, the government has been investing huge sums in surveillance of phone calls of American citizens. "Checking every phone call ever made is an example of old think," he said. He was alluding to databases maintained at an AT&T data center in Kansas, which now contain electronic records of 1.92 trillion telephone calls, going back decades. The Electronic Frontier Foundation, a digital-rights advocacy group, has asserted in a lawsuit that the AT&T Daytona system, a giant storehouse of calling records and Internet message routing information, was the foundation of the N.S.A.'s effort to mine telephone records without a warrant. An AT&T spokeswoman said the company would not comment on the claim, or generally on matters of national security or customer privacy. But the mining of the databases in other law enforcement investigations is well established, with documented results. One application of the database technology, called Security Call Analysis and Monitoring Platform, or Scamp, offers access to about nine weeks of calling information. It currently handles about 70,000 queries a month from fraud and law enforcement investigators, according to AT&T documents. A former AT&T official who had detailed knowledge of the call-record database said the Daytona system takes great care to make certain that anyone using the database b whether AT&T employee or law enforcement official with a subpoena b sees only information he or she is authorized to see, and that an audit trail keeps track of all users. Such information is frequently used to build models of suspects' social networks. The official, speaking on condition of anonymity because he was discussing sensitive corporate matters, said every telephone call generated a record: number called, time of call, duration of call, billing category and other details. While the database does not contain such billing data as names, addresses and credit card numbers, those records are in a linked database that can be tapped by authorized users. New calls are entered into the database immediately after they end, the official said, adding, "I would characterize it as near real time." According to a current AT&T employee, whose identity is being withheld to avoid jeopardizing his job, the mining of the AT&T databases had a notable success in helping investigators find the perpetrators of what was known as the Moldovan porn scam. In 1997 a shadowy group in Moldova, a former Soviet republic, was tricking Internet users by enticing them to a pornography Web site that would download a piece of software that disconnected the computer user from his local telephone line and redialed a costly 900 number in Moldova. While another long-distance carrier simply cut off the entire nation of Moldova from its network, AT&T and the Moldovan authorities were able to mine the database to track the culprits. Much of the recent work on data mining has been aimed at even more sophisticated applications. The National Security Agency has invested billions in computerized tools for monitoring phone calls around the world b not only logging them, but also determining content b and more recently in trying to design digital vacuum cleaners to sweep up information from the Internet. Last September, the N.S.A. was granted a patent for a technique that could be used to determine the physical location of an Internet address b another potential category of data to be mined. The technique, which exploits the tiny time delays in the transmission of Internet data, suggests the agency's interest in sophisticated surveillance tasks like trying to determine where a message sent from an Internet address in a cybercafe might have originated. An earlier N.S.A. patent, in 1999, focused on a software solution for generating a list of topics from computer-generated text. Such a capacity hints at the ability to extract the content of telephone conversations automatically. That might permit the agency to mine millions of phone conversations and then select a handful for human inspection. As the N.S.A. visit to the Silicon Valley venture capitalists this month indicates, the actual development of such technologies often comes from private companies. In 2003, Virage, a Silicon Valley company, began supplying a voice transcription product that recognized and logged the text of television programming for government and commercial customers. Under perfect conditions, the system could be 95 percent accurate in capturing spoken text. Such technology has potential applications in monitoring phone conversations as well. And several Silicon Valley executives say one side effect of the 2003 decision to cancel the Total Information Awareness project was that it killed funds for a research project at the Palo Alto Research Center, a subsidiary of Xerox, exploring technologies that could protect privacy while permitting data mining. The aim was to allow an intelligence analyst to conduct extensive data mining without getting access to identifying information about individuals. If the results suggested that, for instance, someone might be a terrorist, the intelligence agency could seek a court warrant authorizing it to penetrate the privacy technology and identify the person involved. With Xerox funds, the Palo Alto researchers are continuing to explore the technology. Scott Shane contributed reporting from Washington for this article. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: leaker-optimized versions of Tor
by Gregory Maxwell 06 Jul '18

06 Jul '18

On Wed, Dec 8, 2010 at 10:11 AM, Mitar <mmitar(a)gmail.com> wrote: > Hi! > >> Relaxing the realtime constraint, adding random delays, more >> hops and also chaff trafic in a Tor derivate would arguably >> make such attacks more difficult. > > I am asking just about more hops. Why would more hops be necessary? It > is enough that one node introduces random delay and this is it? It is strictly necessary that the bad guy not control 100% of the forwarding nodes. On a realtime onion network anonymity is bounded by timing attacksb even if you could tolerate the delay of having a zillion middle nodes the attacker could just watch the entrances an exits and correlate timing. So adding a great many hops would not significantly increase security. A mix network can tolerate higher delays and, hopefully, eliminates the timing attacks. So additional hops can be beneficial. The down side is increased vulnerability to DOS attacks if flooders can generate cheap round-the-world messages. The creating a hidden service based overlay network, as was suggested here by Karsten N., was what I thought when I read the threadb but I was concerned that if the network identity of all/most of the nodes is hidden that an attacker could spin up thousands of fake mix nodes without even needing a lot of network resources. They could make it far more likely that all your hops were controlled by one party. Although the risk exists for non hidden service based designs, it's probably much easier with an anonymity layer in between. Any design using hidden services would specifically need to address this risk. *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: leaker-optimized versions of Tor
by Gregory Maxwell 06 Jul '18

06 Jul '18

On Wed, Dec 8, 2010 at 10:11 AM, Mitar <mmitar(a)gmail.com> wrote: > Hi! > >> Relaxing the realtime constraint, adding random delays, more >> hops and also chaff trafic in a Tor derivate would arguably >> make such attacks more difficult. > > I am asking just about more hops. Why would more hops be necessary? It > is enough that one node introduces random delay and this is it? It is strictly necessary that the bad guy not control 100% of the forwarding nodes. On a realtime onion network anonymity is bounded by timing attacksb even if you could tolerate the delay of having a zillion middle nodes the attacker could just watch the entrances an exits and correlate timing. So adding a great many hops would not significantly increase security. A mix network can tolerate higher delays and, hopefully, eliminates the timing attacks. So additional hops can be beneficial. The down side is increased vulnerability to DOS attacks if flooders can generate cheap round-the-world messages. The creating a hidden service based overlay network, as was suggested here by Karsten N., was what I thought when I read the threadb but I was concerned that if the network identity of all/most of the nodes is hidden that an attacker could spin up thousands of fake mix nodes without even needing a lot of network resources. They could make it far more likely that all your hops were controlled by one party. Although the risk exists for non hidden service based designs, it's probably much easier with an anonymity layer in between. Any design using hidden services would specifically need to address this risk. *********************************************************************** To unsubscribe, send an e-mail to majordomo(a)torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [p2p-hackers] Re: Memory and reputation calculation
by Paul Campbell 06 Jul '18

06 Jul '18

With regards to the history function, I recall seeing a paper (no idea where or what the title was) that looked at it a different way. The concern is that in a P2P environment, there's no central assumed tamper-proof central server. One must rely on the peers themselves for history. It would be relatively easy for a peer to simply erase and ignore bad history, or for peers to be able to collude to report false history, unless one of two things happens: 1. The vector/group concept of Advogato among others prevents collusion simply because there are no multple paths...the false history shows up as a self-referential structure and not as a web of trust links. The group/vector concept searches for multiple disjoint paths of trust, which lessens or destroys collusion. 2. That the history passed on by a peer should be serialized in such a way that it is tamper-proof. That is, the client can't selectively delete events from the history. For instance, a one-way accumulator-type function intertwined into the data performs the protection. It doesn't circumvent the possibility of a client simply deleting the last few events in the history (and nothing is going to stop a client from doing a snapshot to achieve this), but it at least makes such selective editting an all-or-nothing function. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)zgp.org http://zgp.org/mailman/listinfo/p2p-hackers _______________________________________________ Here is a web page listing P2P Conferences: http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[IP] Taking Spying to Higher Level, Agencies Look for More Ways to Mine Data,By JOHN MARKOFF
by Dave Farber 06 Jul '18

06 Jul '18

The New York Times February 25, 2006 Taking Spying to Higher Level, Agencies Look for More Ways to Mine Data By JOHN MARKOFF PALO ALTO, Calif., Feb. 23 b A small group of National Security Agency officials slipped into Silicon Valley on one of the agency's periodic technology shopping expeditions this month. On the wish list, according to several venture capitalists who met with the officials, were an array of technologies that underlie the fierce debate over the Bush administration's anti-terrorist eavesdropping program: computerized systems that reveal connections between seemingly innocuous and unrelated pieces of information. The tools they were looking for are new, but their application would fall under the well-established practice of data mining: using mathematical and statistical techniques to scan for hidden relationships in streams of digital data or large databases. Supercomputer companies looking for commercial markets have used the practice for decades. Now intelligence agencies, hardly newcomers to data mining, are using new technologies to take the practice to another level. But by fundamentally changing the nature of surveillance, high-tech data mining raises privacy concerns that are only beginning to be debated widely. That is because to find illicit activities it is necessary to turn loose software sentinels to examine all digital behavior whether it is innocent or not. "The theory is that the automated tool that is conducting the search is not violating the law," said Mark D. Rasch, the former head of computer-crime investigations for the Justice Department and now the senior vice president of Solutionary, a computer security company. But "anytime a tool or a human is looking at the content of your communication, it invades your privacy." When asked for comment about the meetings in Silicon Valley, Jane Hudgins, a National Security Agency spokeswoman, said, "We have no information to provide." Data mining is already being used in a diverse array of commercial applications b whether by credit card companies detecting and stopping fraud as it happens, or by insurance companies that predict health risks. As a result, millions of Americans have become enmeshed in a vast and growing data web that is constantly being examined by a legion of Internet-era software snoops. Technology industry executives and government officials said that the intelligence agency systems take such techniques further, applying software analysis tools now routinely used by law enforcement agencies to identify criminal activities and political terrorist organizations that would otherwise be missed by human eavesdroppers. One such tool is Analyst's Notebook, a crime investigation "spreadsheet" and visualization tool developed by i2 Inc., a software firm based in McLean, Va. The software, which ranges in price from as little as $3,000 for a sheriff's department to millions of dollars for a large government agency like the Federal Bureau of Investigation, allows investigators to organize and view telephone and financial transaction records. It was used in 2001 by Joyce Knowlton, an investigator at the Stillwater State Correctional Facility in Minnesota, to detect a prison drug-smuggling ring that ultimately implicated 30 offenders who were linked to Supreme White Power, a gang active in the prison. Ms. Knowlton began her investigation by importing telephone call records into her software and was immediately led to a pattern of calls between prisoners and a recent parolee. She overlaid the calling data with records of prisoners' financial accounts, and based on patterns that emerged, she began monitoring phone calls of particular inmates. That led her to coded messages being exchanged in the calls that revealed that seemingly innocuous wood blocks were being used to smuggle drugs into the prison. "Once we added the money and saw how it was flowing from addresses that were connected to phone numbers, it created a very clear picture of the smuggling ring," she said. Privacy, of course, is hardly an expectation for prisoners. And credit card customers and insurance policyholders give up a certain amount of privacy to the issuers and carriers. It is the power of such software tools applied to broad, covert governmental uses that has led to the deepening controversy over data mining. In the wake of 9/11, the potential for mining immense databases of digital information gave rise to a program called Total Information Awareness, developed by Adm. John M. Poindexter, the former national security adviser, while he was a program manager at the Defense Advanced Research Projects Agency. Although Congress abruptly canceled the program in October 2003, the legislation provided a specific exemption for "processing, analysis and collaboration tools for counterterrorism foreign intelligence." At the time, Admiral Poindexter, who declined to be interviewed for this article because he said he had knowledge of current classified intelligence activities, argued that his program had achieved a tenfold increase in the speed of the searching databases for foreign threats. While agreeing that data mining has a tremendous power for fighting a new kind of warfare, John Arquilla, a professor of defense analysis at the Naval Postgraduate School in Monterey, Calif., said that intelligence agencies had missed an opportunity by misapplying the technologies. "In many respects, we're fighting the last intelligence war," Mr. Arquilla said. "We have not pursued data mining in the way we should." Mr. Arquilla, who was a consultant on Admiral Poindexter's Total Information Awareness project, said that the $40 billion spent each year by intelligence agencies had failed to exploit the power of data mining in correlating information readily available from public sources, like monitoring Internet chat rooms used by Al Qaeda. Instead, he said, the government has been investing huge sums in surveillance of phone calls of American citizens. "Checking every phone call ever made is an example of old think," he said. He was alluding to databases maintained at an AT&T data center in Kansas, which now contain electronic records of 1.92 trillion telephone calls, going back decades. The Electronic Frontier Foundation, a digital-rights advocacy group, has asserted in a lawsuit that the AT&T Daytona system, a giant storehouse of calling records and Internet message routing information, was the foundation of the N.S.A.'s effort to mine telephone records without a warrant. An AT&T spokeswoman said the company would not comment on the claim, or generally on matters of national security or customer privacy. But the mining of the databases in other law enforcement investigations is well established, with documented results. One application of the database technology, called Security Call Analysis and Monitoring Platform, or Scamp, offers access to about nine weeks of calling information. It currently handles about 70,000 queries a month from fraud and law enforcement investigators, according to AT&T documents. A former AT&T official who had detailed knowledge of the call-record database said the Daytona system takes great care to make certain that anyone using the database b whether AT&T employee or law enforcement official with a subpoena b sees only information he or she is authorized to see, and that an audit trail keeps track of all users. Such information is frequently used to build models of suspects' social networks. The official, speaking on condition of anonymity because he was discussing sensitive corporate matters, said every telephone call generated a record: number called, time of call, duration of call, billing category and other details. While the database does not contain such billing data as names, addresses and credit card numbers, those records are in a linked database that can be tapped by authorized users. New calls are entered into the database immediately after they end, the official said, adding, "I would characterize it as near real time." According to a current AT&T employee, whose identity is being withheld to avoid jeopardizing his job, the mining of the AT&T databases had a notable success in helping investigators find the perpetrators of what was known as the Moldovan porn scam. In 1997 a shadowy group in Moldova, a former Soviet republic, was tricking Internet users by enticing them to a pornography Web site that would download a piece of software that disconnected the computer user from his local telephone line and redialed a costly 900 number in Moldova. While another long-distance carrier simply cut off the entire nation of Moldova from its network, AT&T and the Moldovan authorities were able to mine the database to track the culprits. Much of the recent work on data mining has been aimed at even more sophisticated applications. The National Security Agency has invested billions in computerized tools for monitoring phone calls around the world b not only logging them, but also determining content b and more recently in trying to design digital vacuum cleaners to sweep up information from the Internet. Last September, the N.S.A. was granted a patent for a technique that could be used to determine the physical location of an Internet address b another potential category of data to be mined. The technique, which exploits the tiny time delays in the transmission of Internet data, suggests the agency's interest in sophisticated surveillance tasks like trying to determine where a message sent from an Internet address in a cybercafe might have originated. An earlier N.S.A. patent, in 1999, focused on a software solution for generating a list of topics from computer-generated text. Such a capacity hints at the ability to extract the content of telephone conversations automatically. That might permit the agency to mine millions of phone conversations and then select a handful for human inspection. As the N.S.A. visit to the Silicon Valley venture capitalists this month indicates, the actual development of such technologies often comes from private companies. In 2003, Virage, a Silicon Valley company, began supplying a voice transcription product that recognized and logged the text of television programming for government and commercial customers. Under perfect conditions, the system could be 95 percent accurate in capturing spoken text. Such technology has potential applications in monitoring phone conversations as well. And several Silicon Valley executives say one side effect of the 2003 decision to cancel the Total Information Awareness project was that it killed funds for a research project at the Palo Alto Research Center, a subsidiary of Xerox, exploring technologies that could protect privacy while permitting data mining. The aim was to allow an intelligence analyst to conduct extensive data mining without getting access to identifying information about individuals. If the results suggested that, for instance, someone might be a terrorist, the intelligence agency could seek a court warrant authorizing it to penetrate the privacy technology and identify the person involved. With Xerox funds, the Palo Alto researchers are continuing to explore the technology. Scott Shane contributed reporting from Washington for this article. ------------------------------------- You are subscribed as eugen(a)leitl.org To manage your subscription, go to http://v2.listbox.com/member/?listname=ip Archives at: http://www.interesting-people.org/archives/interesting-people/ ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0

Re: [liberationtech] What I've learned from Cryptocat
by Ali-Reza Anghaie 06 Jul '18

06 Jul '18

On Mon, Aug 6, 2012 at 8:43 PM, Jillian C. York <jilliancyork(a)gmail.com> wrote: > It's difficult. I'm not a technologist, but I understand the issues and the > user needs well. My "type," I'd surmise, is few and far between. The problem isn't that your type is few and far between - the problem is that InfoSec has almost wholly ignored ESTABLISHED activists. As if the techniques, acceptable risk levels, etc. are new issues. They're simply not. > Security experts have obvious reasons for being conservative, and I get > that. Nevertheless, there are a lot of users who would benefit from a > little bit of added security. The question, then, as I see it, is: > > How do we provide that little bit while still making users aware of risks? It's been my experience that providing these risks in-band is just not doable - and the target end-users don't have time to worry about it. So OPSEC has to be something that tools like Cryptocat don't assume responsibility for. These is InfoSec sacrilege but it's the way activists have traditionally had to work in the first place. As an example, lets say w/ Iran, you're never - ever - going to be able to address the OPSEC concerns of a given Internet cafe. What you can do instead is provide a tool that works from every possible cafe and trust the end-user to manage the OPSEC of their surroundings such that perimeter controls, MITM risks, etc. are mitigated another way. If that's not tenable for Nadim or his particular crowd then a shift from developer to activist needs to be made. Just like any other process, the product isn't out their for product's sake - it has "customers".. and it's not those people who think they need an easier lazier option to setting up OTR or PGP. BTW, you're not without understanding and support in the Security community. Meredith Patterson among others have batted this around with me on Twitter - and understand the economics of the situation fine. Good luck Nadim and friends, -Ali _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[drone-list] IDF shoots down drone in Israeli airspace
by Gregory Foster 06 Jul '18

06 Jul '18

Jerusalem Post (Oct 6) - "IDF: Unmanned aerial vehicle shot down in northern Negev": http://www.jpost.com/Defense/Article.aspx?id=286845 IDF is being cagey about or doesn't know the source of the drone: http://twitter.com/AvitalLeibovich/status/254573007052357633 gf -- Gregory Foster || gfoster(a)entersection.org @gregoryfoster <> http://entersection.com/ _______________________________________________ drone-list mailing list drone-list(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/drone-list If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. Should you need immediate assistance, please contact the list moderator. ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

report on security risks of applying CALEA to VoIP
by Susan Landau 06 Jul '18

06 Jul '18

Tuesday 13 June 2006 at 10:35 Below you'll find an executive summary of "Security Implications of Applying the Communications Assistance for Law Enforcement Act to Voice over IP," by Steve Bellovin, Matt Blaze, Ernie Brickell, Clint Brooks, Vint Cerf, Whit Diffie, Susan Landau, Jon Peterson, John Treichler. The full report is at: http://www.itaa.org/news/docs/CALEAVOIPreport.pdf. Susan Security Implications of Applying the Communications Assistance to Law Enforcement Act to Voice over IP Steven Bellovin, Columbia University Matt Blaze, University of Pennsylvania Ernest Brickell, Intel Corporation Clinton Brooks, NSA (retired) Vinton Cerf, Google Whitfield Diffie, Sun Microsystems Susan Landau, Sun Microsystems Jon Peterson, NeuStar John Treichler, Applied Signal Technology Executive Summary For many people, Voice over Internet Protocol (VoIP) looks like a nimble way of using a computer to make phone calls. Download the software, pick an identifier and then wherever there is an Internet connection, you can make a phone call. From this perspective, it makes perfect sense that anything that can be done with a telephone, including the graceful accommodation of wiretapping, should be able to be done readily with VoIP as well. The FCC has issued an order for all ``interconnected'' and all broadband access VoIP services to comply with Communications Assistance for Law Enforcement Act (CALEA) --- without specific regulations on what compliance would mean. The FBI has suggested that CALEA should apply to all forms of VoIP, regardless of the technology involved in the VoIP implementation. Intercept against a VoIP call made from a fixed location with a fixed IP address directly to a big internet provider's access router is equivalent to wiretapping a normal phone call, and classical PSTN-style CALEA concepts can be applied directly. In fact, these intercept capabilities can be exactly the same in the VoIP case if the ISP properly secures its infrastructure and wiretap control process as the PSTN's central offices are assumed to do. However, the network architectures of the Internet and the Public Switched Telephone Network (PSTN) are substantially different, and these differences lead to security risks in applying the CALEA to VoIP. VoIP, like most Internet communications, are communications for a mobile environment. The feasibility of applying CALEA to more decentralized VoIP services is quite problematic. Neither the manageability of such a wiretapping regime nor whether it can be made secure against subversion seem clear. The real danger is that a CALEA-type regimen is likely to introduce serious vulnerabilities through its ``architected security breach.'' Potential problems include the difficulty of determining where the traffic is coming from (the VoIP provider enables the connection but may not provide the services for the actual conversation), the difficulty of ensuring safe transport of the signals to the law-enforcement facility, the risk of introducing new vulnerabilities into Internet communications, and the difficulty of ensuring proper minimization. VOIP implementations vary substantially across the Internet making it impossible to implement CALEA uniformly. Mobility and the ease of creating new identities on the Internet exacerbate the problem. Building a comprehensive VoIP intercept capability into the Internet appears to require the cooperation of a very large portion of the routing infrastructure, and the fact that packets are carrying voice is largely irrelevant. Indeed, most of the provisions of the wiretap law do not distinguish among different types of electronic communications. Currently the FBI is focused on applying CALEA's design mandates to VoIP, but there is nothing in wiretapping law that would argue against the extension of intercept design mandates to all types of Internet communications. Indeed, the changes necessary to meet CALEA requirements for VoIP would likely have to be implemented in a way that covered all forms of Internet communication. In order to extend authorized interception much beyond the easy scenario, it is necessary either to eliminate the flexibility that Internet communications allow, or else introduce serious security risks to domestic VoIP implementations. The former would have significant negative effects on U.S. ability to innovate, while the latter is simply dangerous. The current FBI and FCC direction on CALEA applied to VoIP carries great risks. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)metzdowd.com ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

1 0