July 2018 - cypherpunks-legacy

Re: [tor-talk] Tor and P2P
by grarpamp 06 Jul '18

06 Jul '18

Allow me to combine some quotes from this recent thread alone... > I've had an idea for a while for a killer service for... > I'd be very much interested to see it in reality. I guess the > delays will be more then acceptable. > it would be cool to have a more general protocol for P2P use > through hidden services. > Hidden Services as a globally anonymous NAT'd networked is an > amazing opportunity for this type of application. It seems pretty clear we are at the point where there are current and growing ideas and demand for all manner of anonymous P2P services. In part driven by global news, and thus global awareness, that governments, business and others have questionable regard for privacy, etc. And if consumers continue to demand and drive openness into products, there will soon come a day when open, BSD/Linux capable, pad devices (PC + wifi + cell) the size of a DVD case are common. Demand, compounded by utility. Regardless of the capacity for the sort of projects listed below to handle it, people WILL build these services. Some of them are out there today, and being largely unknown, they are performing well enough. More users will try them and adopt them based on need, utility and performance. The only question is how will the networks perform at each stage of popularity. Given that these services are surely coming in force... and from directions that see these networks more as a raw transport than say, primarily for the purposes outlined on their respective web pages... it seems the usual echo of "we're a nice project, don't do that, too much load" may not be useful. This should not imply fault, but merely suggest that it's dated and hopeless. And since the networks are anonymous, countermeasures would affect all users matching the metric, even those using it for said purposes. So maybe there's room for more focused/funded research into the actual impacts of different traffic models (leading to proper resource giveback by apps/users/groups), development improvement in the networks to handle the traffic, even up to creating an entirely new anonymous network optimized for P2P ... > It is not unheard of for apps that work well and do something > cool to suddently have 1M+ users ... before this certainty happens. > which isn't to say you shouldn't build this. > What should I do then to have anonymous and secure decentralized > chat, file sharing and the like on Tor? > We just need to solve the scalability problem so we do not, as > Robert put it "thrash the hidden services directory". Do what is needed to go forth and conquer :) P2P services should look at the current strong anonymization projects that could provide transport. The ones I know of are: http://www.i2p2.de/ https://code.google.com/p/phantom/ https://www.torproject.org/ More links are welcome. People should not make the mistake of assuming they can freely use any network without negative impact. Including fatal impact for their own service. They should offer sufficient resources back to the network. Contrary to popular belief, P2P is not a free ride. Relay, directory and index is expensive and the cost is bandwidth, CPU and storage. _______________________________________________ tor-talk mailing list tor-talk(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Data Retention in UK?
by Lexi Pimenidis 06 Jul '18

06 Jul '18

Hej, I don't know to which extend already details about upcoming details on data retention in European countries != Germany hav been posted here. I just found this on the Internet: http://www.independent.co.uk/news/uk/home-news/government-black-boxes-will-… http://www.heise-online.co.uk/news/British-government-will-reportedly-recor… "[..]Government circles are considering the use of a black box technology to monitor email messages and web access on a grand scale.[..]" So: logging of *content* will be likely. "[..]According to them, the black boxes will be secure and won't require any direct input from ISPs. Many smaller ISPs, it is said, would be unaffected by the black boxes, because these would be installed upstream on the network.[..]" I read this as: the government wants to log, but does not trust the ISPs to do the job, and possibly they do not even want to disclose what they are actually logging. If I interpret these correctly, this law is coming into effect beginning of next year. Are there more news? What about France, Spain, the Netherlands? -- Lexi -- Jhvk.-Hcofmn. Kqph Vhnqchjhb, Kqlmgqmqhwl orqm HZ-Bhwlqmlqhz Marn: LW 8325, Lfqkjqmkhcbzm. 3, Bhqxqc, Zqk: +49-271-740-2408 | Lagq crc, awl! Vlhkfbfvlhq, Yrmhbzqmqh rcj Nqjhthc, | Rcj kqhjqm arwl Zlqfkfxhq! Jrmwlarb bzrjhqmz, nhz lqhbbqn Gqnrqlc. | Ja bzql hwl crc, hwl amnqm Zfm! Rcj ghc bf ukrx akb ihq trsfm; ----- 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-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

On Apr 29, 2009, at 11:51 AM, Nathan wrote: > http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf Wow! These slides say that they discovered a way to find collisions in SHA-1 at a cost of only 2^52 computations. If this turns out to be right (and the authors are respected cryptographers -- the kind of people who really hate to be wrong about something like this) then it is very exciting! SHA-1 was already known to be vulnerable to attack by a moderately well-funded organization such as a national security agency, national military, corporation, or organized criminal group. Now it turns out that finding SHA-1 collisions is in the reach of a dedicated hobbyist or an eccentric genius [1]. Let's put a rough number on it. I might be a little bit off, but you can build a COPACOBANA machine for about $10,000 [2], and it can brute-force a 56- bit DES key in about six and a half days. 2^52 SHA-1 operations should take roughly the same amount of time and money. As another example I guess that distributed computation engines [3] and botnets [4] might be able to generate a SHA-1 collision in seconds. Plus of course the amplifying effects of birthday attacks and rainbow tables and so on mean that the longer you keep your COPACOBANA or your botnet generating SHA-1 collisions, the more SHA-1 users around the world become vulnerable to you. So basically, if these slides are right then relying on SHA-1 collision-resistance has been revealed as a major vulnerability! Almost all hash functions in civilian, open use are either MD5 or SHA-1. For example, decentralized revision control tools such as monotone, git, and hg rely on SHA-1. Interesting times! As Shawn already correctly pointed out (and as Nathan probably already knew), Tahoe doesn't use SHA-1, so we're not affected by this new discovery. Tahoe-LAFS uses SHA-256 (in the "double-hashing" mode suggested by Ferguson and Schneier and named "SHA-256d"). We also add our own tagging and salting prefix to avoid certain problems. We aren't currently vulnerable to hash collision attacks, and we plan never to get into that position (about which more below). Nonetheless, it would be a very good exercise to spell out what sorts of problems could result if attackers could violate what sorts of properties of the hash function(s) used in Tahoe. The basic uses of secure hashes in Tahoe are for integrity-checking of immutable files and for digital signatures on mutable files and directories. If an attacker could generate two different inputs which yielded the same hash output (that is, to find a "hash collision"), then they could give you a single immutable file cap that produced two (or more) different files when you used it to download the file. We believe that nobody is currently able to do that, so currently if someone gives you an immutable file cap, you can rely on there being at most one file which can be downloaded using that cap. For mutable files it is even safer. If an attacker could find an input which yielded the same output as someone *else*'s input (that is, to find a "second pre-image"), then that attacker could write changes to a mutable file or directory that they were not authorized to write to. Finding a second pre-image is probably much harder than finding a collision -- for example nobody has yet figured out how to find a second pre-image in SHA-1. That's why I say it is even safer. You already assume that the person who can write to a mutable file can make it so that two or more different file contents would be downloaded from using the same mutable-file read cap, but for immutable files we hold them to a higher standard and prevent even the original uploader of the immutable file from being able to make more than one file that matches the immutable-file read cap. There are a lot more details of how Tahoe uses hash functions that I would be happy to work out when I have time, but those are the most important ones, and the immutable file caps are the most likely to turn out to be vulnerable. (Although, as I've said, even the immutable file caps are extremely unlikely to be vulnerable.) (Hm, this puts an interesting twist on Vincent and Nathan's idea of layering Mercurial-or-Bazaar on top of Tahoe. Tahoe uses stronger cryptography (and also more flexible cryptography, by the way), so if you have uploaded your Mercurial repository to Tahoe then even when SHA-1 turns out to be weak (as it has), you can still rely on the integrity of your repository.) > ps: For the case of Merkel Trees, are any security guarantees > preserved in the face of hash collision attacks? Sure -- a Merkle Tree has collision-resistance if the underlying hash has collision-resistance, and a Merkle Tree has second-preimage- resistance if the underlying hash has second-preimage resistance. So if the underlying has doesn't have collision-resistance but does have second-preimage-resistance (as we currently suspect that SHA-1 might), then your Merkle Tree would stil have second-preimage- resistance. Also a Merkle Tree might be stronger than its underlying hash function in a few ways, even if the underlying hash is somewhat weak. > d. For an existing grid how feasible is an upgrade to a new hash > format which preserves all data? It is certainly possible to preserve all the data. The obvious way is to download your files and re-upload them in the new format. I suspect that will probably end up being the best way, too. I would like to emphasize that it is extremely unlikely that anyone will need to do this due to a weakness in the hashing algorithm in Tahoe in a hurry. The people who are suffering from the collisions in MD5 and SHA-1 are suffering, not because MD5 or SHA-1 were suddenly revealed to be insecure, but because they ignored the warning messages from cryptographers for many years. (I'm a tad irritated about this, since "I tried to tell them" [5] and "They wouldn't listen!" [6].) By the time that SHA-256 (plus our tagging and salting) is vulnerable to collisions, which could be anywhere from five years to a hundred years from now, we will have already upgraded Tahoe to use a stronger hash function (SHA-3 or a SHA-3 candidate) and gracefully upgraded pre-existing files. Now the actual details of securely upgrading extant files to new integrity check mechanisms could be interesting. We've thought a bit about how to facilitate future graceful upgrades and this will no doubt prompt us to think about it some more. The stickiest bits are in the capability itself. Let's put it this way: suppose you upload a file to a Tahoe grid today and get an immutable read cap in return. Then suppose a few years from now someone does some unspecified operation which adds stronger hashes to the file as it exists out there on the servers. Now, how do you as the holder of the original immutable read cap know that those new stronger hashes are correct? You don't, because your read-cap wasn't generated from those new stronger hashes. This isn't a weakness in the Tahoe capability-oriented design, it's more of a fundamental problem which is just thrown into sharper light by the cap design. You can, of course, choose to delegate your decision about whether or not the file is correct to someone else (using Tahoe as well as using any other scheme), but if you want to actually have certainty *yourself* that the file is correct using the new hashes, then you're going to have to do some sort of download and computation on the file yourself, using the new hash algorithm. Regards, Zooko [1] http://www.toad.com/gnu [2] http://en.wikipedia.org/wiki/Custom_hardware_attack [3] http://en.wikipedia.org/wiki/List_of_distributed_computing_projects [4] http://en.wikipedia.org/wiki/Bot_nets [5] http://www.gelato.unsw.edu.au/archives/git/0506/5273.html [6] http://www.gelato.unsw.edu.au/archives/git/0506/5299.html _______________________________________________ tahoe-dev mailing list tahoe-dev(a)allmydata.org http://allmydata.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

[Politech] White House deal says FISA court will review NSA spying [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

News coverage: http://www.nytimes.com/2006/07/14/washington/14nsa.html --- Electronic Frontier Foundation Media Release For Immediate Release: Friday, July 14, 2006 Proposed Surveillance Bill Would Sweep NSA Spying Programs Under the Rug Bill Threatens Future of EFF Case and Other Legal Challenges San Francisco - Senate Judiciary Committee Chairman Arlen Specter said today that he has negotiated a proposed bill with the White House regarding the NSA's illegal spying program. While the final bill is not public, a draft of the bill obtained by the Electronic Frontier Foundation (EFF) is a sham compromise that would cut off meaningful legal review -- sweeping current legal challenges out of the traditional court system and failing to require court review or congressional oversight of any future surveillance programs. "This so-called compromise bill is not a concession from the White House -- it's a rubber stamp for any future spying program dreamed up by the executive," said EFF Staff Attorney Kevin Bankston. "In essence, this bill threatens to make court oversight of electronic surveillance voluntary rather than mandatory." Although the bill creates a process for the executive branch to seek court review of its secret surveillance programs, it doesn't actually require the government to do so. The bill would, however, require that any lawsuit challenging the legality of any classified surveillance program -- including EFF's class-action suit against AT&T -- be transferred, at the government's request, to the FISA Court of Review, a secret court with no procedures for hearing argument from anyone but the government. The bill would further allow the government to prevent the court from disclosing any information about the government's surveillance programs to opposing counsel, regardless of the court's strict security procedures. "When the privacy of millions of Americans is at stake, we deserve more than a closed hearing by a secret court," said EFF Senior Staff Attorney Lee Tien. For the draft of the Specter bill: http://www.eff.org/Privacy/Surveillance/NSA/specter_draftbill_071306.pdf For this release: http://www.eff.org/news/archives/2006_07.php#004824 About EFF The Electronic Frontier Foundation is the leading civil liberties organization working to protect rights in the digital world. Founded in 1990, EFF actively encourages and challenges industry and government to support free expression and privacy online. EFF is a member-supported organization and maintains one of the most linked-to websites in the world at http://www.eff.org/ -end- _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

Data Retention in UK?
by Lexi Pimenidis 06 Jul '18

06 Jul '18

Hej, I don't know to which extend already details about upcoming details on data retention in European countries != Germany hav been posted here. I just found this on the Internet: http://www.independent.co.uk/news/uk/home-news/government-black-boxes-will-… http://www.heise-online.co.uk/news/British-government-will-reportedly-recor… "[..]Government circles are considering the use of a black box technology to monitor email messages and web access on a grand scale.[..]" So: logging of *content* will be likely. "[..]According to them, the black boxes will be secure and won't require any direct input from ISPs. Many smaller ISPs, it is said, would be unaffected by the black boxes, because these would be installed upstream on the network.[..]" I read this as: the government wants to log, but does not trust the ISPs to do the job, and possibly they do not even want to disclose what they are actually logging. If I interpret these correctly, this law is coming into effect beginning of next year. Are there more news? What about France, Spain, the Netherlands? -- Lexi -- Jhvk.-Hcofmn. Kqph Vhnqchjhb, Kqlmgqmqhwl orqm HZ-Bhwlqmlqhz Marn: LW 8325, Lfqkjqmkhcbzm. 3, Bhqxqc, Zqk: +49-271-740-2408 | Lagq crc, awl! Vlhkfbfvlhq, Yrmhbzqmqh rcj Nqjhthc, | Rcj kqhjqm arwl Zlqfkfxhq! Jrmwlarb bzrjhqmz, nhz lqhbbqn Gqnrqlc. | Ja bzql hwl crc, hwl amnqm Zfm! Rcj ghc bf ukrx akb ihq trsfm; ----- 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-dev] SHA-1 broken! (was: Request for hash-dependency in Tahoe security.)
by Zooko O'Whielacronx 06 Jul '18

06 Jul '18

On Apr 29, 2009, at 11:51 AM, Nathan wrote: > http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf Wow! These slides say that they discovered a way to find collisions in SHA-1 at a cost of only 2^52 computations. If this turns out to be right (and the authors are respected cryptographers -- the kind of people who really hate to be wrong about something like this) then it is very exciting! SHA-1 was already known to be vulnerable to attack by a moderately well-funded organization such as a national security agency, national military, corporation, or organized criminal group. Now it turns out that finding SHA-1 collisions is in the reach of a dedicated hobbyist or an eccentric genius [1]. Let's put a rough number on it. I might be a little bit off, but you can build a COPACOBANA machine for about $10,000 [2], and it can brute-force a 56- bit DES key in about six and a half days. 2^52 SHA-1 operations should take roughly the same amount of time and money. As another example I guess that distributed computation engines [3] and botnets [4] might be able to generate a SHA-1 collision in seconds. Plus of course the amplifying effects of birthday attacks and rainbow tables and so on mean that the longer you keep your COPACOBANA or your botnet generating SHA-1 collisions, the more SHA-1 users around the world become vulnerable to you. So basically, if these slides are right then relying on SHA-1 collision-resistance has been revealed as a major vulnerability! Almost all hash functions in civilian, open use are either MD5 or SHA-1. For example, decentralized revision control tools such as monotone, git, and hg rely on SHA-1. Interesting times! As Shawn already correctly pointed out (and as Nathan probably already knew), Tahoe doesn't use SHA-1, so we're not affected by this new discovery. Tahoe-LAFS uses SHA-256 (in the "double-hashing" mode suggested by Ferguson and Schneier and named "SHA-256d"). We also add our own tagging and salting prefix to avoid certain problems. We aren't currently vulnerable to hash collision attacks, and we plan never to get into that position (about which more below). Nonetheless, it would be a very good exercise to spell out what sorts of problems could result if attackers could violate what sorts of properties of the hash function(s) used in Tahoe. The basic uses of secure hashes in Tahoe are for integrity-checking of immutable files and for digital signatures on mutable files and directories. If an attacker could generate two different inputs which yielded the same hash output (that is, to find a "hash collision"), then they could give you a single immutable file cap that produced two (or more) different files when you used it to download the file. We believe that nobody is currently able to do that, so currently if someone gives you an immutable file cap, you can rely on there being at most one file which can be downloaded using that cap. For mutable files it is even safer. If an attacker could find an input which yielded the same output as someone *else*'s input (that is, to find a "second pre-image"), then that attacker could write changes to a mutable file or directory that they were not authorized to write to. Finding a second pre-image is probably much harder than finding a collision -- for example nobody has yet figured out how to find a second pre-image in SHA-1. That's why I say it is even safer. You already assume that the person who can write to a mutable file can make it so that two or more different file contents would be downloaded from using the same mutable-file read cap, but for immutable files we hold them to a higher standard and prevent even the original uploader of the immutable file from being able to make more than one file that matches the immutable-file read cap. There are a lot more details of how Tahoe uses hash functions that I would be happy to work out when I have time, but those are the most important ones, and the immutable file caps are the most likely to turn out to be vulnerable. (Although, as I've said, even the immutable file caps are extremely unlikely to be vulnerable.) (Hm, this puts an interesting twist on Vincent and Nathan's idea of layering Mercurial-or-Bazaar on top of Tahoe. Tahoe uses stronger cryptography (and also more flexible cryptography, by the way), so if you have uploaded your Mercurial repository to Tahoe then even when SHA-1 turns out to be weak (as it has), you can still rely on the integrity of your repository.) > ps: For the case of Merkel Trees, are any security guarantees > preserved in the face of hash collision attacks? Sure -- a Merkle Tree has collision-resistance if the underlying hash has collision-resistance, and a Merkle Tree has second-preimage- resistance if the underlying hash has second-preimage resistance. So if the underlying has doesn't have collision-resistance but does have second-preimage-resistance (as we currently suspect that SHA-1 might), then your Merkle Tree would stil have second-preimage- resistance. Also a Merkle Tree might be stronger than its underlying hash function in a few ways, even if the underlying hash is somewhat weak. > d. For an existing grid how feasible is an upgrade to a new hash > format which preserves all data? It is certainly possible to preserve all the data. The obvious way is to download your files and re-upload them in the new format. I suspect that will probably end up being the best way, too. I would like to emphasize that it is extremely unlikely that anyone will need to do this due to a weakness in the hashing algorithm in Tahoe in a hurry. The people who are suffering from the collisions in MD5 and SHA-1 are suffering, not because MD5 or SHA-1 were suddenly revealed to be insecure, but because they ignored the warning messages from cryptographers for many years. (I'm a tad irritated about this, since "I tried to tell them" [5] and "They wouldn't listen!" [6].) By the time that SHA-256 (plus our tagging and salting) is vulnerable to collisions, which could be anywhere from five years to a hundred years from now, we will have already upgraded Tahoe to use a stronger hash function (SHA-3 or a SHA-3 candidate) and gracefully upgraded pre-existing files. Now the actual details of securely upgrading extant files to new integrity check mechanisms could be interesting. We've thought a bit about how to facilitate future graceful upgrades and this will no doubt prompt us to think about it some more. The stickiest bits are in the capability itself. Let's put it this way: suppose you upload a file to a Tahoe grid today and get an immutable read cap in return. Then suppose a few years from now someone does some unspecified operation which adds stronger hashes to the file as it exists out there on the servers. Now, how do you as the holder of the original immutable read cap know that those new stronger hashes are correct? You don't, because your read-cap wasn't generated from those new stronger hashes. This isn't a weakness in the Tahoe capability-oriented design, it's more of a fundamental problem which is just thrown into sharper light by the cap design. You can, of course, choose to delegate your decision about whether or not the file is correct to someone else (using Tahoe as well as using any other scheme), but if you want to actually have certainty *yourself* that the file is correct using the new hashes, then you're going to have to do some sort of download and computation on the file yourself, using the new hash algorithm. Regards, Zooko [1] http://www.toad.com/gnu [2] http://en.wikipedia.org/wiki/Custom_hardware_attack [3] http://en.wikipedia.org/wiki/List_of_distributed_computing_projects [4] http://en.wikipedia.org/wiki/Bot_nets [5] http://www.gelato.unsw.edu.au/archives/git/0506/5273.html [6] http://www.gelato.unsw.edu.au/archives/git/0506/5299.html _______________________________________________ tahoe-dev mailing list tahoe-dev(a)allmydata.org http://allmydata.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

[p2p-hackers] Privacy issues with P2P protocols
by Arnaud Legout 06 Jul '18

06 Jul '18

Hi, I would like to point you to a recent work we made that we believe might be of interest to the BitTorrent/P2P community. In this work that was presented at IMC'11, we show what we believe to be a significant privacy issue for most P2P protocols. -We show that leveraging on Skype, we can map a social identity (name, age, location, email address, etc.) to an IP address fully inconspicuously. This attack works for all (500M) Skype users. This is severe as an attacker does not need the ISP support (that an individual cannot usually get) to retrieve the social identity linked to an IP address. -We show that we can then follow the mobility of a Skype user, and we found that we can indeed observe real mobility patterns for a large fraction of Skype users. -Finally, we were able to link a Skype identity to a list of BitTorrent downloads even if the user is behind a NAT or a proxy (we use the predictability of the IP-ID in IP headers to make sure that two different applications are running on the same host). That attack described uses Skype, but would also work with several other popular VoIP systems. All details are available here: http://hal.inria.fr/inria-00632780/en/ Regards, Arnaud. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[Politech] White House deal says FISA court will review NSA spying [priv]
by Declan McCullagh 06 Jul '18

06 Jul '18

News coverage: http://www.nytimes.com/2006/07/14/washington/14nsa.html --- Electronic Frontier Foundation Media Release For Immediate Release: Friday, July 14, 2006 Proposed Surveillance Bill Would Sweep NSA Spying Programs Under the Rug Bill Threatens Future of EFF Case and Other Legal Challenges San Francisco - Senate Judiciary Committee Chairman Arlen Specter said today that he has negotiated a proposed bill with the White House regarding the NSA's illegal spying program. While the final bill is not public, a draft of the bill obtained by the Electronic Frontier Foundation (EFF) is a sham compromise that would cut off meaningful legal review -- sweeping current legal challenges out of the traditional court system and failing to require court review or congressional oversight of any future surveillance programs. "This so-called compromise bill is not a concession from the White House -- it's a rubber stamp for any future spying program dreamed up by the executive," said EFF Staff Attorney Kevin Bankston. "In essence, this bill threatens to make court oversight of electronic surveillance voluntary rather than mandatory." Although the bill creates a process for the executive branch to seek court review of its secret surveillance programs, it doesn't actually require the government to do so. The bill would, however, require that any lawsuit challenging the legality of any classified surveillance program -- including EFF's class-action suit against AT&T -- be transferred, at the government's request, to the FISA Court of Review, a secret court with no procedures for hearing argument from anyone but the government. The bill would further allow the government to prevent the court from disclosing any information about the government's surveillance programs to opposing counsel, regardless of the court's strict security procedures. "When the privacy of millions of Americans is at stake, we deserve more than a closed hearing by a secret court," said EFF Senior Staff Attorney Lee Tien. For the draft of the Specter bill: http://www.eff.org/Privacy/Surveillance/NSA/specter_draftbill_071306.pdf For this release: http://www.eff.org/news/archives/2006_07.php#004824 About EFF The Electronic Frontier Foundation is the leading civil liberties organization working to protect rights in the digital world. Founded in 1990, EFF actively encourages and challenges industry and government to support free expression and privacy online. EFF is a member-supported organization and maintains one of the most linked-to websites in the world at http://www.eff.org/ -end- _______________________________________________ Politech mailing list Archived at http://www.politechbot.com/ Moderated by Declan McCullagh (http://www.mccullagh.org/) ----- 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

[p2p-hackers] Privacy issues with P2P protocols
by Arnaud Legout 06 Jul '18

06 Jul '18

Hi, I would like to point you to a recent work we made that we believe might be of interest to the BitTorrent/P2P community. In this work that was presented at IMC'11, we show what we believe to be a significant privacy issue for most P2P protocols. -We show that leveraging on Skype, we can map a social identity (name, age, location, email address, etc.) to an IP address fully inconspicuously. This attack works for all (500M) Skype users. This is severe as an attacker does not need the ISP support (that an individual cannot usually get) to retrieve the social identity linked to an IP address. -We show that we can then follow the mobility of a Skype user, and we found that we can indeed observe real mobility patterns for a large fraction of Skype users. -Finally, we were able to link a Skype identity to a list of BitTorrent downloads even if the user is behind a NAT or a proxy (we use the predictability of the IP-ID in IP headers to make sure that two different applications are running on the same host). That attack described uses Skype, but would also work with several other popular VoIP systems. All details are available here: http://hal.inria.fr/inria-00632780/en/ Regards, Arnaud. _______________________________________________ p2p-hackers mailing list p2p-hackers(a)lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Re: [drone-list] NYT: How much UAV surveillance are you comfortable with?
by Harley_Geiger 06 Jul '18

06 Jul '18

There is no real Constitutional question with regard to prohibiting individual or corporate surveillance carried out via drones. On the contrary, private individuals/companies using drones to video or photograph people and objects in public places could argue they have a First Amendment right to do so. There are some laws (i.e., state voyeurism laws) that prohibit taking footage of individuals in places in which they may expect privacy, but generally not in public places. I'm not as clear on this, but I believe private entities can use drones to take footage of private property as well, though, again, with some restrictions (i.e., CA Civ. Code 1708.8). The Fourth Amendment applies to government surveillance via drones, but in a limited (I would say anachronistic) fashion under Supreme Court interpretations. In Florida v. Riley, police did not need a warrant to conduct aerial surveillance of private property from a helicopter; essentially the Court ruled that private citizens do not own or have privacy rights to airspace roughly 400ft above the property. In Kyllo v. United States, the Supreme Court ruled police did need a warrant to use a thermal imaging camera to peer inside an individual's home. Taken together, these cases suggest the government generally does not need a warrant to use a drone to conduct aerial surveillance over a broad area that includes both public and private property, so long as the drone is not equipped with sensors that can penetrate the walls of homes and other legally recognized private areas (sheds, possibly car interiors, etc.). Why are people uncomfortable with drone surveillance? Because drones can quietly watch an entire town for many hours without refueling, enabling a pervasive, secret surveillance that helicopters or traffic cameras cannot match. Low-end models are cheap enough that anyone b a global corporation, your homeowner's association, your creepy neighbor b can purchase a drone (a parrot drone is $300 on Amazon). Importantly, you cannot really avoid a drone, at least not if you're outside. I think people realize there are very few limits on what information can be collected and shared via drones b so what if every time stepped out of the house you were on YouTube? Privacy law is not ready for drones. If you're interested, I've written two blog posts on drones and privacy. This is the first one: https://www.cdt.org/blogs/harley-geiger/2112drones-are-coming This is the latest one: https://www.cdt.org/blogs/harley-geiger/092congress-demands-drones-over-ame… - Harley Geiger Policy Counsel Center for Democracy & Technology 202-407-8825 harley(a)cdt.org On Feb 19, 2012, at 6:54 PM, M Edward Borasky wrote: > On Sun, Feb 19, 2012 at 11:44 AM, Martyn Williams <martyn(a)stanford.edu> wrote: >> I'm interested in this privacy question and would like to look a bit >> more closely at it. >> >> Law enforcement, public safety, news organizations, and private >> companies are already flying over our backyards and taking pictures. >> >> Depending on where you live, Google has even put this online (zoom in on >> Google Maps and at max zoom it changes from satellite imagery to photos >> captured by aircraft). >> >> I'm not suggesting everyone is happy with that, but it doesn't seem to >> provoke the same reaction as the issue of drones. > > I for one am not happy that Google is allowed to perform aerial > surveillance on citizens of any democracy. It seems to me there's a > Constitutional question in the USA. The government in theory can't do > that without a court order. and journalists can in theory be shielded > by the First Amendment if they keep their act together. But a > for-profit corporation apparently has to be in violation of some other > law to incur even a Congressional inquiry, and a private citizen must > have a *lot* of money to mount a successful civil action against a > business as huge as Google. > > Some places - Germany, IIRC - have attempted to rein in Google's > "Street View" surveillance, but I don't think anyone has even broached > the subject in the USA. We should. >> >> So, what exactly makes us uncomfortable about drones? >> >> Is it that they're anonymous and remote-controlled? That they can stay >> up for hours? Perhaps it's the link with what we've seen the military >> doing? Or perhaps it's that they are capturing video and not >> photographic images. >> >> I don't have any great insight into this, but I think we need to figure >> out the objections before we can talk about legislation and regulation. > > All of the above. The Constitution protects us from our government in > theory, but apparently not from corporations large enough to implement > surveillance for profit. >> >> Personally, I have less problem with a drone being used to follow and >> catch a criminal after a crime takes place (much like a helicopter is >> used today) than one patrolling my neighborhood for hours on end >> monitoring what's happening. >> >> Similarly, I don't want my neighbor hovering a drone above my garden, >> but if they can get pretty much the same view from hovering near the >> boundary line then an airspace restriction might be ineffective. >> >> Martyn >> >> >> On 02/18/2012 03:55 PM, M Edward Borasky wrote: >>> The question is not "How Much Am I Comfortable With?" It's "What >>> actions can I *legally* take to protect my privacy? I'm guessing I >>> can't block law enforcement drones or interfere with them in any way, >>> but private sector operation over my property is quite another matter. >>> >> >> -- >> Martyn Williams >> 2012 John S. Knight Journalism Fellow >> Stanford University >> @martyn_williams >> _______________________________________________ >> 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. > > > > -- > Twitter: http://twitter.com/znmeb Data Journalism Developer Studio > 2012LX http://j.mp/DJDS2012LX > > "A mathematician is a device for turning coffee into theorems." -- Paul ErdEs > _______________________________________________ > 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. _______________________________________________ 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