July 2018 - cypherpunks-legacy

None
by None 06 Jul '18

06 Jul '18

-- Rayservers http://www.rayservers.com/ Zurich: +41 43 5000 728 London: +44 20 30 02 74 72 Panama: +507 832 1846 San Francisco: +1 408 419 1978 USA Toll Free: +1 888 265 5009 10:00 - 24:00 GMT We prefer to be paid in gold Globalsb" and silver Islesb" Global Standardb" - Global Settlement Foundation http://www.global-settlement.org/ Our PGP key for support(a)rayservers.com 0x079CCE10 on http://keyserver.rayservers.com/

1 0

None
by Chris 06 Jul '18

06 Jul '18

2011 10:45:13 -0400 ________________________________ Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. That day is coming through US force as "Operation Gun Runner" from the ATF allowed Mexican drug cartel straw purchasers to come in, purchase 5 or so AK-47 rifles, and when the gun store owner had suspicions about not selling it - the ATF told the owner to "let the guns walk" so the group could track down the weapons. Unfortunately, those weapons were used to kill a DEA agent in Mexico and a Border Patrol agent who was only armed with bean bag rounds in his shotgun then died trying to cycle out those rounds to put in live rounds. Also with al-CIAda patsy Adam Gahdan inaccurately reporting in his latest video to other jihadists about purchasing "automatic weapons" from gun shows, I believe the ball is rolling for everyone in the United States to be disarmed through force by new legislation to outlaw weapons. I do not think the average gun owner would ever disarm because the gun culture in our country is so deep and passionate in any freedom loving citizen's blood. The Second Amendment, in my opinion and most gun owners agree with, was put in the Bill of Rights for the average citizen to remove tyrants if the process of democracy does not work. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. Better get one before it's too late :-) -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton

1 0

None
by None 06 Jul '18

06 Jul '18

-- Rayservers http://www.rayservers.com/ Zurich: +41 43 5000 728 London: +44 20 30 02 74 72 Panama: +507 832 1846 San Francisco: +1 408 419 1978 USA Toll Free: +1 888 265 5009 10:00 - 24:00 GMT We prefer to be paid in gold Globalsb" and silver Islesb" Global Standardb" - Global Settlement Foundation http://www.global-settlement.org/ Our PGP key for support(a)rayservers.com 0x079CCE10 on http://keyserver.rayservers.com/

1 0

None
by Chris 06 Jul '18

06 Jul '18

2011 10:45:13 -0400 ________________________________ Once law enforcement is effective enough to prevent the average criminal from having access to firearms, then the law-abiding population can be compelled to disarm. That day is coming through US force as "Operation Gun Runner" from the ATF allowed Mexican drug cartel straw purchasers to come in, purchase 5 or so AK-47 rifles, and when the gun store owner had suspicions about not selling it - the ATF told the owner to "let the guns walk" so the group could track down the weapons. Unfortunately, those weapons were used to kill a DEA agent in Mexico and a Border Patrol agent who was only armed with bean bag rounds in his shotgun then died trying to cycle out those rounds to put in live rounds. Also with al-CIAda patsy Adam Gahdan inaccurately reporting in his latest video to other jihadists about purchasing "automatic weapons" from gun shows, I believe the ball is rolling for everyone in the United States to be disarmed through force by new legislation to outlaw weapons. I do not think the average gun owner would ever disarm because the gun culture in our country is so deep and passionate in any freedom loving citizen's blood. The Second Amendment, in my opinion and most gun owners agree with, was put in the Bill of Rights for the average citizen to remove tyrants if the process of democracy does not work. At present, the average criminal in my area does not have firearms, and so I do not own one. Gun crime is on the increase, however, so this situation may change. Better get one before it's too late :-) -- --C "The dumber people think you are, the more surprised they're going to be when you kill them." - Sir William Clayton

1 0

How I Learned to Stop Ph34ring NSA and Love the Base Rate Fallacy
by The23rd Raccoon 06 Jul '18

06 Jul '18

Abstract Ladies and gentlemen, I am a Raccoon who has learned to do math. It used to be the case that on the Internet, nobody knew you were a Raccoon. But now that Privacy is dead, I've decided to come clean. I present to you this anonymously authored, non-peer reviewed communication to do with what you will. Should anyone actually cite this work in a published paper, I will ask my brethren to leave their garbage cans unmolested for the rest of their days. Introduction This post performs some basic analysis of the utility of timing correlation attacks against a moderately used anonymous network, specifically with respect to the Base Rate Fallacy[1] of Bayesian statistics. Via that same analysis, it also for the first time begins to quantify the utility that additional users bring to a low latency anonymous network in terms of resistance to timing attacks. You see, one day I was rifling through the local University dumpster looking for a free meal, and I stumbled upon a pile of discarded conference proceedings which I decided to peruse while I dined. After a while, it became apparent that many papers dealing with timing and correlation attacks completely ignore the Base Rate Fallacy and the effect of larger user bases and sample sizes on their results. Worse, while it may be possible that some papers actually DO report Bayesian Detection Rate probabilities, those that do never specify this fact, making their work impossible to differentiate from less appetizing dumpster morsels. It was enough to get this Raccoon down, and I survive contently on moldy bread and discarded hot dogs[2]! Event Notation and Grounding Most timing attack papers deal with the true positive rate and the false positive rate of detection. So let's establish some symbols and formalize these two rates. M = Two chosen entry and exit streams Match (are the same stream) ~M = Two chosen entry and exit streams Don't Match (are not the same) C = Packet/stream timing Correlation predicts a pair is matching ~C = Packet/stream timing Correlation predicts a pair is Non-matching True Positive Rate: P(C|M) False Negative Rate: P(~C|M) = 1-P(C|M) True Negative Rate: P(~C|~M) = 1-P(C|~M) False Positive Rate: P(C|~M) Bayesian Detection Rate Derivation Given a purely hypothetical network with 250,000 concurrent users generating approximately 5000 network-wide concurrent streams and a 99.9% accurate (Equal Error Rate) generic correlation detector, find the probability that we actually DO have a matching entry+exit pair given our Correlator says that we do. This is known as the Bayesian Detection Rate, and is written as P(M|C). >From Bayes: P(M|C) = P(C|M)*P(M)/P(C) Summing out M to obtain P(C): P(C) = P(M)*P(C|M) + P(~M)*P(C|~M) Combined: P(M|C) = P(C|M)*P(M)/(P(M)*P(C|M) + P(~M)*P(C|~M)) Example 1: Fully Correlating Global Adversary This example deals with an adversary trying to correlate EVERYTHING on a 5000 concurrent stream network at all times. 5000 concurrent streams means 5000 entry connections and 5000 exit connections (as an approximation). This gives 5000^2 possible entry-exit pairings network-wide, thus: P(M) = (1/5000)^2 = 4E-8 99.9% EER generic correlation detector: P(C|M) = 0.999 P(C|~M) = 0.001 P(M|C) = 0.999*4E-8/(4E-8*0.999 + (1-4E-8)*0.001) P(M|C) = .00004 or .004%. In other words, we expect that for every 25000 times the correlator predicts a matching pair, only one of those actually is a valid match. So much for dragnet surveillance. Example 2: Single Site-targeting Global Adversary In this example, the adversary is only interested in connections to a particular site, say wikileaks.org. For this, let's say the adversary only has one exit stream at a given time to correlate to a given entry stream, giving: P(M) = 1/5000 = .0002 P(M|C) = 0.999*.0002/(.0002*0.999 + (1-.0002)*0.001) P(M|C) = .1666 = 16.66% So this means that we expect the adversary to have 6 suspect users for every user that leaks a document to wikileaks.org for a 99.9% accurate correlator. Unlike the dragnet adversary, the targeted adversary is still pretty effective, especially since they will almost certainly have additional a-priori information about the users they suspect to have done the leak. However, if their correlator drops to just 99% EER, however, P(M|C) drops to 0.0194 or 1.94%. At 90% EER, P(M|C) is 0.0018 or 0.18%. These provide with expectations of confusion sets of 52 and 556 users respectively. Example 3: Single Site-targeting "Local" Adversary To extend this into the capabilities of a local adversary (as opposed to global), insert a (c/n)^2 factor into P(M) to account for the likelihood that the adversary will see both sides of a connection, where c is the percentage of network bandwidth they control, and n is the total network capacity. Common accepted reasonable values for c/n are on the order of 0.1, though this may be much higher for IX-level yet not quite fully global adversaries[3]. Let's go with 0.3. P(M) = (1/5000)*(0.3)^2 = .000018 P(M|C) = 0.999*.000018/(.000018*0.999 + (1-.000018)*.001) P(M|C) = 0.0177 = 1.77% So this means that an adversary with control of 30% of the network (such as China, the US, or Germany) can expect to go through 57 other users before coming across a legitimate match predicted by their timing detector. At 99% EER, this number goes up to 562, and at 90% EER, all the way up to 6173. This seems a bit more infeasible, but may still be doable with enough information or many repeated observations. Conclusions So what does this all mean? Well, first of all, it underscores the importance of being absolutely clear in timing attack research about exactly what success probabilities are being reported, so we can better compare both attacks and defenses. In fact, in the opinion of this humble Raccoon, a large body of work is somewhat suspect for lack of clarity, both in this and other respects. Second, it gives us a small glimmer of hope that maybe all is not lost against IX, National, or ISP level adversaries. Especially those with only sampled or connection-level resolution, where fine-grained details on inter-packet timings is not available (as will likely be the case with EU data retention). Finally, it also quantifies that we certainly do benefit from a larger anonymity network not just in terms of nodes, but also in terms of total concurrent users doing similar things (like short-lived web traffic). This quantification strongly indicates that we should avoid splitting the network into segments if we want to gain any additional utility from growing it further, aside from simply supporting more users at some fixed level of anonymity. [1]. http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf [2]. http://www.stinkymeat.net/ [3]. http://www.cl.cam.ac.uk/~sjm217/papers/pet07ixanalysis.pdf [4]. "If you only cite a handful of works, either you are doing something incredibly novel, or you're not nearly as novel as you thought." [5]. "Good artists imitate, great artists steal." ----- 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

[tahoe-announce] ANNOUNCING Tahoe-LAFS v1.7.0
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Dear people of tahoe-dev and tahoe-announce mailing lists: I am *very* pleased to announce v1.7.0! This is an excellent release, of highest quality, with improvements contributed by a band of "hackers in the public interest" from all over the world. This release carries on our tradition of compatibility and reliability so that you can upgrade to v1.7 without hesitation. Below is the official release announcement. Spread the word! Regards, Zooko, Release Manager ANNOUNCING Tahoe, the Least-Authority File System, v1.7.0 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.7.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning that not even the operator of your storage server can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html Tahoe-LAFS v1.7.0 is the successor to v1.6.1, which was released February 27, 2010 [1]. v1.7.0 is a major new release with new features and bugfixes. It adds a fully functional SFTP interface, support for non-ASCII character encodings, and a new upload algorithm which guarantees that each file is spread over multiple servers for fault-tolerance. See the NEWS file [2] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers are compromised by by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems. These include frontends for Windows, Macintosh, JavaScript, iPhone, and Android, and plugins for Hadoop, bzr, mercurial, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or "cloud storage" systems. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all currently known issues please see the known_issues.txt file [4].) COMPATIBILITY This release is fully compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the ninth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with Tahoe-LAFS v1. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to wait for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they have continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Thank you to Allmydata, Inc. for their generous and public-spirited support. Google, Inc. is sponsoring Tahoe-LAFS development as part of the Google Summer of Code 2010. Google suggested that we should apply for the Summer of Code program, and when we did they generously awarded four sponsorships to students from around the world to hack on Tahoe-LAFS this summer. Thank you to Google, Inc. for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the fifth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. In this release we especially owe thanks to David-Sarah Hopwood, who has dedicated many late nights to the project and displayed superb software engineering skills. Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team June 18, 2010 Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4244 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4254 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4511 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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

new tech report on easy-to-use IPsec
by Steven Bellovin 06 Jul '18

06 Jul '18

Folks on this list may be interested in a new tech report: Shreyas Srivatsan, Maritza Johnson, and Steven M. Bellovin. Simple-VPN: Simple IPsec configuration. Technical Report CUCS-020-10, Department of Computer Science, Columbia University, July 2010. http://mice.cs.columbia.edu/getTechreport.php?techreportID=1433 The IPsec protocol promised easy, ubiquitous encryption. That has never happened. For the most part, IPsec usage is confined to VPNs for road warriors, largely due to needless configuration complexity and incompatible implementations. We have designed a simple VPN configuration language that hides the unwanted complexities. Virtually no options are necessary or possible. The administrator specifies the absolute minimum of information: the authorized hosts, their operating systems, and a little about the network topology; everything else, including certificate generation, is automatic. Our implementation includes a multitarget compiler, which generates implementation-specific configuration files for three different platforms; others are easy to add. We hope to have the code up on Sourceforge soon. --Steve Bellovin, http://www.cs.columbia.edu/~smb --------------------------------------------------------------------- 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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

How I Learned to Stop Ph34ring NSA and Love the Base Rate Fallacy
by The23rd Raccoon 06 Jul '18

06 Jul '18

Abstract Ladies and gentlemen, I am a Raccoon who has learned to do math. It used to be the case that on the Internet, nobody knew you were a Raccoon. But now that Privacy is dead, I've decided to come clean. I present to you this anonymously authored, non-peer reviewed communication to do with what you will. Should anyone actually cite this work in a published paper, I will ask my brethren to leave their garbage cans unmolested for the rest of their days. Introduction This post performs some basic analysis of the utility of timing correlation attacks against a moderately used anonymous network, specifically with respect to the Base Rate Fallacy[1] of Bayesian statistics. Via that same analysis, it also for the first time begins to quantify the utility that additional users bring to a low latency anonymous network in terms of resistance to timing attacks. You see, one day I was rifling through the local University dumpster looking for a free meal, and I stumbled upon a pile of discarded conference proceedings which I decided to peruse while I dined. After a while, it became apparent that many papers dealing with timing and correlation attacks completely ignore the Base Rate Fallacy and the effect of larger user bases and sample sizes on their results. Worse, while it may be possible that some papers actually DO report Bayesian Detection Rate probabilities, those that do never specify this fact, making their work impossible to differentiate from less appetizing dumpster morsels. It was enough to get this Raccoon down, and I survive contently on moldy bread and discarded hot dogs[2]! Event Notation and Grounding Most timing attack papers deal with the true positive rate and the false positive rate of detection. So let's establish some symbols and formalize these two rates. M = Two chosen entry and exit streams Match (are the same stream) ~M = Two chosen entry and exit streams Don't Match (are not the same) C = Packet/stream timing Correlation predicts a pair is matching ~C = Packet/stream timing Correlation predicts a pair is Non-matching True Positive Rate: P(C|M) False Negative Rate: P(~C|M) = 1-P(C|M) True Negative Rate: P(~C|~M) = 1-P(C|~M) False Positive Rate: P(C|~M) Bayesian Detection Rate Derivation Given a purely hypothetical network with 250,000 concurrent users generating approximately 5000 network-wide concurrent streams and a 99.9% accurate (Equal Error Rate) generic correlation detector, find the probability that we actually DO have a matching entry+exit pair given our Correlator says that we do. This is known as the Bayesian Detection Rate, and is written as P(M|C). >From Bayes: P(M|C) = P(C|M)*P(M)/P(C) Summing out M to obtain P(C): P(C) = P(M)*P(C|M) + P(~M)*P(C|~M) Combined: P(M|C) = P(C|M)*P(M)/(P(M)*P(C|M) + P(~M)*P(C|~M)) Example 1: Fully Correlating Global Adversary This example deals with an adversary trying to correlate EVERYTHING on a 5000 concurrent stream network at all times. 5000 concurrent streams means 5000 entry connections and 5000 exit connections (as an approximation). This gives 5000^2 possible entry-exit pairings network-wide, thus: P(M) = (1/5000)^2 = 4E-8 99.9% EER generic correlation detector: P(C|M) = 0.999 P(C|~M) = 0.001 P(M|C) = 0.999*4E-8/(4E-8*0.999 + (1-4E-8)*0.001) P(M|C) = .00004 or .004%. In other words, we expect that for every 25000 times the correlator predicts a matching pair, only one of those actually is a valid match. So much for dragnet surveillance. Example 2: Single Site-targeting Global Adversary In this example, the adversary is only interested in connections to a particular site, say wikileaks.org. For this, let's say the adversary only has one exit stream at a given time to correlate to a given entry stream, giving: P(M) = 1/5000 = .0002 P(M|C) = 0.999*.0002/(.0002*0.999 + (1-.0002)*0.001) P(M|C) = .1666 = 16.66% So this means that we expect the adversary to have 6 suspect users for every user that leaks a document to wikileaks.org for a 99.9% accurate correlator. Unlike the dragnet adversary, the targeted adversary is still pretty effective, especially since they will almost certainly have additional a-priori information about the users they suspect to have done the leak. However, if their correlator drops to just 99% EER, however, P(M|C) drops to 0.0194 or 1.94%. At 90% EER, P(M|C) is 0.0018 or 0.18%. These provide with expectations of confusion sets of 52 and 556 users respectively. Example 3: Single Site-targeting "Local" Adversary To extend this into the capabilities of a local adversary (as opposed to global), insert a (c/n)^2 factor into P(M) to account for the likelihood that the adversary will see both sides of a connection, where c is the percentage of network bandwidth they control, and n is the total network capacity. Common accepted reasonable values for c/n are on the order of 0.1, though this may be much higher for IX-level yet not quite fully global adversaries[3]. Let's go with 0.3. P(M) = (1/5000)*(0.3)^2 = .000018 P(M|C) = 0.999*.000018/(.000018*0.999 + (1-.000018)*.001) P(M|C) = 0.0177 = 1.77% So this means that an adversary with control of 30% of the network (such as China, the US, or Germany) can expect to go through 57 other users before coming across a legitimate match predicted by their timing detector. At 99% EER, this number goes up to 562, and at 90% EER, all the way up to 6173. This seems a bit more infeasible, but may still be doable with enough information or many repeated observations. Conclusions So what does this all mean? Well, first of all, it underscores the importance of being absolutely clear in timing attack research about exactly what success probabilities are being reported, so we can better compare both attacks and defenses. In fact, in the opinion of this humble Raccoon, a large body of work is somewhat suspect for lack of clarity, both in this and other respects. Second, it gives us a small glimmer of hope that maybe all is not lost against IX, National, or ISP level adversaries. Especially those with only sampled or connection-level resolution, where fine-grained details on inter-packet timings is not available (as will likely be the case with EU data retention). Finally, it also quantifies that we certainly do benefit from a larger anonymity network not just in terms of nodes, but also in terms of total concurrent users doing similar things (like short-lived web traffic). This quantification strongly indicates that we should avoid splitting the network into segments if we want to gain any additional utility from growing it further, aside from simply supporting more users at some fixed level of anonymity. [1]. http://www.raid-symposium.org/raid99/PAPERS/Axelsson.pdf [2]. http://www.stinkymeat.net/ [3]. http://www.cl.cam.ac.uk/~sjm217/papers/pet07ixanalysis.pdf [4]. "If you only cite a handful of works, either you are doing something incredibly novel, or you're not nearly as novel as you thought." [5]. "Good artists imitate, great artists steal." ----- 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: 27C3 on Tor
by Roc Admin 06 Jul '18

06 Jul '18

Not sure if anyone else watched the video but of course there is a different story than the Wired article. If you don't want to sit through the whole hour, here's how I would sum it up: The talk in general was about modern tactics for profiling web users. They actually had some interesting stuff to say about how easily and accurately they were able to correlate a user to his or her web traffic but that's off topic. My take away from the entire thing is that there are new technologies to apply machine learning for automated statistical analysis of traffic. In other words, the attacks Nick referenced of 2002 are more feasible. (They do admit that this is nothing new) The same rules apply though and that is you can only be profiled if you are performing the activities that they have in their database and it seems to me that this is more difficult than they make it sound. Profiling a website that has streaming content would be difficult to nail down into a set profile. They conclude by saying that the easiest way to protect yourself is to do multiple things at the same time which increases the likliness that they can profile your activity to their database. I seem to remember a Google Code project that generated random data to obfuscate your fingerprint. Anyone remember? You can see in the video at 31:48 when they start specifically talking about Tor. The specifics of their version of the attack look like this: 1) The attack starts out where the attacker sets up a Tor client running the same OS version and browser and uses tools to profile a website like slashdot.org. 2) their "website profiling tool of doom" makes connections to the website they want to profile. They say that after 2000 requests over a 2 week period, they are able to accurately profile a website no matter what specific content is on the page. This is metadata profiling like packet size, direction, etc. 3) After they have a database of sites, they intercept a Tor client's traffic locally and correlate it with their data. They make a comment that Andriy Panchenko is one of the people that increased the accuracy of this attack by a lot but they don't give the details of what he added. His website is here but I didn't find any details: http://lorre.uni.lu/~andriy/ Prior to his involvement, the attack was at a 3% accuracy. They really don't have any suggestions for the Tor network. They did say that padding, as I originally thought would help, doesn't affect this attack so that wouldn't prevent the attack. Roger, it sounds like you had some specific ideas as to where to put the padding compared to a global value so maybe that's different than what they were talking about. They do comment that TCP fragmentation over the Tor network causes size variation of packets over which makes things easier. Not sure how much value there is in working on that aspect. -- ROC Admin On Tue, Dec 28, 2010 at 11:29 PM, Roger Dingledine <arma(a)mit.edu> wrote: > On Tue, Dec 28, 2010 at 08:51:30PM -0500, Nick Mathewson wrote: >> From the wired.com article, this sounds _exactly_ like the old website >> fingerprinting attack, which has been known since 2002: >> http://freehaven.net/anonbib/#hintz02 >> >> It would be neat if somebody could send a pointer to the authors' >> actual results. > > See also point 3 at > https://www.torproject.org/getinvolved/research.html.en#Ideas > It's been sitting on our "this is important to learn more about" > research list for years. > > It's also listed in the talk I did at 25c3: > http://events.ccc.de/congress/2008/Fahrplan/events/2977.en.html > http://freehaven.net/~arma/slides-25c3.pdf (slide 30) > > So I'm glad to see more attention to the attack, but a bit frustrated that > we (the research community) are not farther along at understanding it. > > Two other things to note: > > The website fingerprinting attack works against other anonymity systems > too, in most cases even more straightforwardly than against Tor. We've > got 8+ years in the literature of applying it to other systems (most > thoroughly just attacking SSL streams to learn what web page is being > fetched despite the encryption), and in the past few years people have > improved the attack to get it to work against Tor also. As I understand > it, even now it only works consistently when they assume laboratory > conditions. That isn't to say that it won't work in real-world conditions > -- just that it's a real hassle to get all the details right so most > researchers don't put in the required engineering work. > > What I'm really looking forward to is learning what modifications to Tor > might slow down the attack. For example, what happens if we move to a 1024 > byte cell by default, or if we randomly add some extra cells periodically, > or if we ask the entry node to add padding cells so the responses we get > are multiples of 10KB? It would seem that there is a tradeoff between > bandwidth overhead (wasted bytes) and protection against this attack, > but I hope there are smart points in the tradeoff space. Alas, we're > still not really to that point yet -- we don't know how well it actually > works in practice against vanilla Tor, so it doesn't make sense to ask > how well it would work in practice against a modified Tor design. > > --Roger > > *********************************************************************** > To unsubscribe, send an e-mail to majordomo(a)torproject.org with > unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ > *********************************************************************** 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

[tahoe-announce] ANNOUNCING Tahoe-LAFS v1.7.0
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

Dear people of tahoe-dev and tahoe-announce mailing lists: I am *very* pleased to announce v1.7.0! This is an excellent release, of highest quality, with improvements contributed by a band of "hackers in the public interest" from all over the world. This release carries on our tradition of compatibility and reliability so that you can upgrade to v1.7 without hesitation. Below is the official release announcement. Spread the word! Regards, Zooko, Release Manager ANNOUNCING Tahoe, the Least-Authority File System, v1.7.0 The Tahoe-LAFS team is pleased to announce the immediate availability of version 1.7.0 of Tahoe-LAFS, an extremely reliable distributed storage system. Tahoe-LAFS is the first distributed storage system which offers "provider-independent security"bmeaning that not even the operator of your storage server can read or alter your data without your consent. Here is the one-page explanation of its unique security and fault-tolerance properties: http://tahoe-lafs.org/source/tahoe/trunk/docs/about.html Tahoe-LAFS v1.7.0 is the successor to v1.6.1, which was released February 27, 2010 [1]. v1.7.0 is a major new release with new features and bugfixes. It adds a fully functional SFTP interface, support for non-ASCII character encodings, and a new upload algorithm which guarantees that each file is spread over multiple servers for fault-tolerance. See the NEWS file [2] for details. WHAT IS IT GOOD FOR? With Tahoe-LAFS, you distribute your filesystem across multiple servers, and even if some of the servers are compromised by by an attacker, the entire filesystem continues to work correctly, and continues to preserve your privacy and security. You can easily share specific files and directories with other people. In addition to the core storage system itself, volunteers have built other projects on top of Tahoe-LAFS and have integrated Tahoe-LAFS with existing systems. These include frontends for Windows, Macintosh, JavaScript, iPhone, and Android, and plugins for Hadoop, bzr, mercurial, duplicity, TiddlyWiki, and more. See the Related Projects page on the wiki [3]. We believe that strong cryptography, Free and Open Source Software, erasure coding, and principled engineering practices make Tahoe-LAFS safer than RAID, removable drive, tape, on-line backup or "cloud storage" systems. This software is developed under test-driven development, and there are no known bugs or security flaws which would compromise confidentiality or data integrity under recommended use. (For all currently known issues please see the known_issues.txt file [4].) COMPATIBILITY This release is fully compatible with the version 1 series of Tahoe-LAFS. Clients from this release can write files and directories in the format used by clients of all versions back to v1.0 (which was released March 25, 2008). Clients from this release can read files and directories produced by clients of all versions since v1.0. Servers from this release can serve clients of all versions back to v1.0 and clients from this release can use servers of all versions back to v1.0. This is the ninth release in the version 1 series. This series of Tahoe-LAFS will be actively supported and maintained for the forseeable future, and future versions of Tahoe-LAFS will retain the ability to read and write files compatible with Tahoe-LAFS v1. LICENCE You may use this package under the GNU General Public License, version 2 or, at your option, any later version. See the file "COPYING.GPL" [5] for the terms of the GNU General Public License, version 2. You may use this package under the Transitive Grace Period Public Licence, version 1 or, at your option, any later version. (The Transitive Grace Period Public Licence has requirements similar to the GPL except that it allows you to wait for up to twelve months after you redistribute a derived work before releasing the source code of your derived work.) See the file "COPYING.TGPPL.html" [6] for the terms of the Transitive Grace Period Public Licence, version 1. (You may choose to use this package under the terms of either licence, at your option.) INSTALLATION Tahoe-LAFS works on Linux, Mac OS X, Windows, Cygwin, Solaris, *BSD, and probably most other systems. Start with "docs/quickstart.html" [7]. HACKING AND COMMUNITY Please join us on the mailing list [8]. Patches are gratefully accepted -- the RoadMap page [9] shows the next improvements that we plan to make and CREDITS [10] lists the names of people who've contributed to the project. The Dev page [11] contains resources for hackers. SPONSORSHIP Tahoe-LAFS was originally developed by Allmydata, Inc., a provider of commercial backup services. After discontinuing funding of Tahoe-LAFS R&D in early 2009, they have continued to provide servers, bandwidth, small personal gifts as tokens of appreciation, and bug reports. Thank you to Allmydata, Inc. for their generous and public-spirited support. Google, Inc. is sponsoring Tahoe-LAFS development as part of the Google Summer of Code 2010. Google suggested that we should apply for the Summer of Code program, and when we did they generously awarded four sponsorships to students from around the world to hack on Tahoe-LAFS this summer. Thank you to Google, Inc. for their generous and public-spirited support. HACK TAHOE-LAFS! If you can find a security flaw in Tahoe-LAFS which is serious enough that feel compelled to warn our users and issue a fix, then we will award you with a customized t-shirts with your exploit printed on it and add you to the "Hack Tahoe-LAFS Hall Of Fame" [12]. ACKNOWLEDGEMENTS This is the fifth release of Tahoe-LAFS to be created solely as a labor of love by volunteers. Thank you very much to the team of "hackers in the public interest" who make Tahoe-LAFS possible. In this release we especially owe thanks to David-Sarah Hopwood, who has dedicated many late nights to the project and displayed superb software engineering skills. Zooko Wilcox-O'Hearn on behalf of the Tahoe-LAFS team June 18, 2010 Boulder, Colorado, USA [1] http://tahoe-lafs.org/trac/tahoe/browser/relnotes.txt?rev=4244 [2] http://tahoe-lafs.org/trac/tahoe/browser/NEWS?rev=4254 [3] http://tahoe-lafs.org/trac/tahoe/wiki/RelatedProjects [4] http://tahoe-lafs.org/trac/tahoe/browser/docs/known_issues.txt [5] http://tahoe-lafs.org/trac/tahoe/browser/COPYING.GPL [6] http://tahoe-lafs.org/source/tahoe/trunk/COPYING.TGPPL.html [7] http://tahoe-lafs.org/source/tahoe/trunk/docs/quickstart.html [8] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev [9] http://tahoe-lafs.org/trac/tahoe/roadmap [10] http://tahoe-lafs.org/trac/tahoe/browser/CREDITS?rev=4511 [11] http://tahoe-lafs.org/trac/tahoe/wiki/Dev [12] http://tahoe-lafs.org/hacktahoelafs/ _______________________________________________ tahoe-announce mailing list tahoe-announce(a)allmydata.org http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-announce ----- 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