July 2018 - cypherpunks-legacy

[IP] PET Award
by David Farber 06 Jul '18

06 Jul '18

Begin forwarded message:

1 0

Re: [p2p-research] Fwd: meeting on p2p risks to national sec
by Paul D. Fernhout 06 Jul '18

06 Jul '18

More from the article: http://www.computerworld.com/s/article/9136053/Details_on_presidential_moto… """ Pointing to the examples offered by Boback, Towns said that the file-sharing industry's promises to regulate itself had clearly failed. "Specific examples of recent LimeWire leaks range from appalling to shocking," Towns said. "As far as I am concerned, the days of self-regulation should be over for the file-sharing industry." Other members want the issue investigated by the Federal Trade Commission, the Securities and Exchange Commission and law enforcement authorities. They said that the continued failure by companies such as LimeWire to take more proactive steps to stop inadvertent file-sharing is tantamount to enabling illegal activity resulting from the data leaks. Towns plans to meet with the chairman of the FTC to determine whether the failure to stop inadvertent file-sharing constitutes an unfair trade practice by P2P companies." """ Anyway, the slashdot comments have lots of rebuttals to those points. http://it.slashdot.org/story/09/07/29/205207/P2P-Network-Exposes-Obamas-Saf… --Paul Fernhout http://www.pdfernhout.net/ _______________________________________________ p2presearch mailing list p2presearch(a)listcultures.org http://listcultures.org/mailman/listinfo/p2presearch_listcultures.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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Blaster / Power Outage Follow up
by Geoff Shively 06 Jul '18

06 Jul '18

As suggested the day of the blackout, SCADA / DCS security was a primary factor in the blackouts. --MSBlast's Effect on the Blackout (29 August 2003) The MSBlast worm apparently slowed some communications lines that connect data centers used to manage the power grid, abetting the "cascading effect" of the blackout that hit the north-east, mid-west and parts of Canada last month. The worm didn't harm the systems, but did slow down the speed at which networks communicated. A Bush administration advisor said that the worm also "hampered efforts to ... restore power in a timely manner." http://www.computerworld.com/printthis/2003/0,4814,84510,00.html Correct after all, this is the second admission of blaster affecting the power systems, one from the Bush administration and one from First Energy. Cheers, Geoff Shively, CHO PivX Solutions, LLC http://www.pivx.com ----- End forwarded message -----

1 0

Re: [p2p-research] Fwd: meeting on p2p risks to national sec
by Paul D. Fernhout 06 Jul '18

06 Jul '18

More from the article: http://www.computerworld.com/s/article/9136053/Details_on_presidential_moto… """ Pointing to the examples offered by Boback, Towns said that the file-sharing industry's promises to regulate itself had clearly failed. "Specific examples of recent LimeWire leaks range from appalling to shocking," Towns said. "As far as I am concerned, the days of self-regulation should be over for the file-sharing industry." Other members want the issue investigated by the Federal Trade Commission, the Securities and Exchange Commission and law enforcement authorities. They said that the continued failure by companies such as LimeWire to take more proactive steps to stop inadvertent file-sharing is tantamount to enabling illegal activity resulting from the data leaks. Towns plans to meet with the chairman of the FTC to determine whether the failure to stop inadvertent file-sharing constitutes an unfair trade practice by P2P companies." """ Anyway, the slashdot comments have lots of rebuttals to those points. http://it.slashdot.org/story/09/07/29/205207/P2P-Network-Exposes-Obamas-Saf… --Paul Fernhout http://www.pdfernhout.net/ _______________________________________________ p2presearch mailing list p2presearch(a)listcultures.org http://listcultures.org/mailman/listinfo/p2presearch_listcultures.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 http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

Blaster / Power Outage Follow up
by Geoff Shively 06 Jul '18

06 Jul '18

As suggested the day of the blackout, SCADA / DCS security was a primary factor in the blackouts. --MSBlast's Effect on the Blackout (29 August 2003) The MSBlast worm apparently slowed some communications lines that connect data centers used to manage the power grid, abetting the "cascading effect" of the blackout that hit the north-east, mid-west and parts of Canada last month. The worm didn't harm the systems, but did slow down the speed at which networks communicated. A Bush administration advisor said that the worm also "hampered efforts to ... restore power in a timely manner." http://www.computerworld.com/printthis/2003/0,4814,84510,00.html Correct after all, this is the second admission of blaster affecting the power systems, one from the Bush administration and one from First Energy. Cheers, Geoff Shively, CHO PivX Solutions, LLC http://www.pivx.com ----- End forwarded message -----

1 0

Re: [liberationtech] FinFisher is now controlled by UK export controls
by Ryan Gallagher 06 Jul '18

06 Jul '18

Export controls on cryptographic items is not a new development in the UK or anywhere else - https://www.gov.uk/specialist/export-of-cryptographic-items The question in the case of FinSpy was whether it was to be classed as a Dual Use item. The UK government appears to now be recognising that FinSpy is indeed a Dual Use item and falls under Annex I of EC export regulations. Annex I is designed to control exports of goods (cryptographic or otherwise) "designed or modified for military use." So what the UK government is implicitly recognising here is that FinSpy can be used as a military tool -- a bit like a weapon -- and should be subject to the same controls. If they implement this, it will mean Gamma will have to make an application for every sale it wants to make outside of the EU, and this will have to be assessed with the Dual Use criteria in mind. So any export will have to be considered in terms of "the respect of human rights and fundamental freedoms in the country of final destination." If the UK government suspects it could be used for internal repression in the country of final destination, for example, they will (theoretically at least) refuse the export. In short, this is progress. Good work Eric. Ryan > Date: Mon, 10 Sep 2012 18:39:51 +0000 > From: jacob(a)appelbaum.net > To: liberationtech(a)lists.stanford.edu > CC: eric(a)privacy.org > Subject: Re: [liberationtech] FinFisher is now controlled by UK export controls > > Eric King: > > Hi all, > > > > I thought this list would be interested to know that the British Government has decided to place FinFisher under UK export controls. There are a ton of questions that remain to be answered, and it's only part of the bigger goal to control the export of surveillance technology, but it's a good first step! > > > >> In a letter sent earlier in August to Privacy International's lawyers Bhatt Murphy, a representative of the Treasury Solicitor stated: > >> > >> The Secretary of State, having carried out an assessment of the FinSpy system to which your letter specifically refers, has advised Gamma International that the system does require a licence to export to all destinations outside the EU under Category 5, Part 2 (bInformation Securityb) of Annex I to the Dual-Use Regulation. This is because it is designed to use controlled cryptography and therefore falls within the scope of Annex I to the Dual-Use Regulation. The Secretary of State also understands that other products in the Finfisher portfolio could be controlled for export in the same way." > >> > >> Press release is here: > >> https://www.privacyinternational.org/press-releases/british-government-admi… -it-has-already-started-controlling-exports-of-gamma > >> > >> Full copy of the letter: https://www.privacyinternational.org/sites/privacyinternational.org/files/d… nloads/press-releases/2012_08_08_response_from_tsol.pdf > > Best, > > > > Eric > > This is absolutely fucking horrible. They're controlling it based on > *cryptography* after we WON the cryptowars? What. The. Fuck. And even > worse, they must require a license? And they don't state categorically > that they'll deny it on some kind of humanitarian or anti-crime related > basis? > > I mean, I am sure this is the result of a lot of hard work by many > people and I don't mean to imply any disrespect. Did this just undercut > the work from the 90s? Wany people explicitly fought hard to win the > decision of having our free speech rights apply to the net for code as > speech. > > Argh, > Jake > > -- > Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/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

[liberationtech] Forbes recommends tools for journalists
by frank＠journalistsecurity.net 06 Jul '18

06 Jul '18

If anyone here has any thoughts about the tools recommended in this Forbes piece, please speak up. The piece gets specific with recommendations form Ashkan Soltani, a technologist who I do not think is on this list, about half way down. Again, any thoughts would be welcome. Thank you! Frank http://www.forbes.com/sites/kashmirhill/2012/12/07/dear-journalists-at-vice… TECH | 12/07/2012 @ 1:33PM |24,858 views Dear Journalists at Vice and Elsewhere, Here Are Some Simple Ways Not To Get Your Source Arrested You forgot to scrub the metadata, suckers. Computer security millionaire John McAfeebs surreal flight from Belizean law enforcement came to an end this week when he was detained (and then hospitalized) in Guatemala, as has been widely reported. A piece of the story that hasnbt been included in much of the reporting is how authorities figured out that McAfee b who was wanted for questioning in the shooting death of his neighbor b had fled Belize for Guatemala. McAfeebs location was exposed after he agreed to let two reporters from Vice Magazine tag along with him. Proud to finally be in the thick of a story rife with vices b drugs, murder, prostitutes, guns, vicious dogs, a fugitive millionaire and his inappropriately young girlfriend b they proudly posted an iPhone photo to their blog of Vice editor-in-chief Rocco Castoro standing with the source of the mayhem in front of a jungly background, saying, b We are with John McAfee right now, suckers.b With that posting, they went from chroniclers of vices to inadvertent narcs. They left the metadata in the photo, revealing McAfeebs exact location, down to latitude and longitude. McAfee tried to claim hebd manipulated the data b a claim that Vice photographer backed up on Facebook in a posting hebs since deleted b but then capitulated, hired a lawyer, and tried to claim asylum in Guatemala. Guatemalan authorities instead detained McAfee for entering the country illegally. All of which was dutifully reported by the Vice reporters, with no mention of their screw-up. Mat Honan at Wired excoriated Vice for its role in events: This was deeply stupid. People have been pointing out the dangers of inadvertently leaving GPS tags in cellphone pictures for years and years. Vice is the same publication that regularly drops in on revolutions and all manner of criminals. They should have known better. And they have the resources to do it better. Vice is a $100 million operation. Then, it followed up this egregiously stupid action with a far worse one. Vice photographer Robert King apparently lied on his Facebook page and Twitter in order to protect McAfee. Like McAfee, he claimed that the geodata in the photo had been manipulated to conceal their true location. b& But the coverup, as always, is worse than the crime. In claiming the geodata had been manipulated when it had not, Vice was no longer just documenting. Now it was actively aiding a fugitive wanted for questioning in the murder investigation of his neighbor Gregory Faull, who was shot dead at his own home. Via How Trusting In Vice Led To John McAfeebs Downfall b Wired. It was indeed deeply stupid. Journalists are professional dealers in information but many are terrible about protecting it. While willing to go to jail to protect their sources, journalists may wind up leaving them exposed instead through poor data practices. In a New York Times editorial last year, Chris Soghoian, now chief technologist at the ACLU, warned that b secrets arenbt safe with journalistsb explaining that b the safety of anonymous sources will depend not only on journalistsb ethics, but on their computer skills.b There are three very basic things journalists should be doing to shield their sources: Scrubbing metadata from photos, documents and other files. Resisting the desire to save copies of everything. Encrypting communications. Technologist Ashkan Soltani walked me through some simple tools for doing this. Theybre not foolproof, but theybll make it a little less likely that your blog post will wind up sending the person youbre profiling to jail (unless thatbs your intent). 1. Scrubbing metadata. b All files b photos, Word docs, PDFs b include some kind of metadata: author, location created, device information,b says Soltani. If you leave the metadata attached, you run the risk of exposing private information about the person who gave you the file, or, in the case of Vice, the location of the person trying to keep his location under wraps. Before you share a Word doc with the world that a source sent you, run it through a scrubber. Otherwise, it may reveal where the doc was created, who authored it and anyone who has ever made changes to it. Therebs Doc Scrubber for Microsoft Word. For PDF docs, use a tool like Metadata Assistant. Or use Adobe Acrobatbs b Examine Documentb tool which will scan the doc for hidden information. For photos, think about turning off geotagging on your phone or digital camera so that the information doesnbt get included in the first place. Youbll usually do that in your phonebs b Location Settings.b Instructions here. You can run your photos through a metadata scrubber. Or, if you donbt care much about the resolution, you can just take a screenshot of the photo and use that metadata-free version. Some photo-hosting services do you the favor of scrubbing metadata. Facebook, Twitter and Instagram all have this privacy-protective measure in place. 2. Resisting the desire to save copies of everything. We live in a time when itbs easy to save everything, meaning webve all become digital hoarders. Why delete an email or chat when you can just archive it? It could come in handy later. Or it could come back to bite you later. b Disable chat logs in whatever program youbre using, Gmail or Skype,b says Soltani. In Gmail, that means switching chats to b off the record.b In Skype, it means turning off the feature that automatically saves your chats to anywhere you log in. (Added privacy bonus: That could keep your boss from winding up getting his hands on a sexy chat you had on your home computer.) If you need to keep a record of a chat, save it as a Word file on your own computer, and encrypt it. b Donbt keep emails around for years and years,b says Soltani. b Practice better data hygiene.b Soltani says journalists and sources might consider setting up temporary email accounts to communicate about a story, and then to delete the accounts after the storybs complete. He compares it to using a burner cell phone. 3. Encrypting your communications. This may be the most labor intensive of the recommendations from computer security professionals, but if itbs important that your communications with someone not be compromised, itbs worth it. This means your emails will appear as gibberish to anyone you donbt want reading them. Had David Petraeus and Paula Broadwell encrypted their emails to one another rather than saving them in a drafts folder, their exposing themselves to each other wouldnbt have been exposed to the world. b This allows you to communicate securely and protects your messages if your account is compromised,b says Soltani. For chat, consider using Adiumbs OTR. Use a Virtual Private Network or create your own SSL. Take 30 minutes (more or less, depending on your savvy level) to set up SMime or PGP for Gmail so that the emails you send from whichever provider you use are encrypted. The only limitation here: you need to get the person youbre communicating with to enable encryption as well. Rather than calling someone from your landline or cell phone, use Skype or Silent Circle. *** A journalistbs job is to bring information to light. Using these tools, youbll retain some control over which information gets lit. 10 Incredibly Simple Things You Can Do To Protect Your Privacy Password Protect Your Devices Choosing not to password protect your devices is the digital equivalent of leaving your home or car unlocked. If you're lucky, no one will take advantage of the access. Or maybe the contents will be ravaged and your favorite speakers and/or secrets stolen. -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/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

Re: nym-0.2 released (fwd)
by Jason Holt 06 Jul '18

06 Jul '18

On Sun, 2 Oct 2005, cyphrpunk wrote: >1. Limting token requests by IP doesn't work in today's internet. Most Hopeless negativism. I limit by IP because that's what Wikipedia is already doing. Sure, hashcash would be easy to add, and I looked into it just last night. Of course, as several have observed, hashcash also leads to whack-a-mole problems, and the abuser doesn't even have to be savvy enough to change IPs. Why aren't digital credential systems more widespread? As has been suggested here and elsewhere at great length, it takes too much infrastructure. It's too easy when writing a security paper to call swaths of CAs into existance with the stroke of the pen. To assume that any moment now, people will start carrying around digital driver's licenses and social security cards (issued in the researcher's pet format), which they'll be happy to show the local library in exchange for a digital library card. That's why I'm so optimistic about nym. A reasonable number of Tor users, a technically inclined group of people on average, want to access a single major site. That site isn't selling ICBMs; they mostly want people to have access anyway. They have an imperfect rationing system based on IPs. The resource is cheap, the policy is simple, and the user needs to conceal a single attribute about herself. There's a simple mathematical solution that yields certificates which are already supported by existing software. That, my friend, is a problem we can solve. >I suggest a proof of work system a la hashcash. You don't have to use >that directly, just require the token request to be accompanied by a >value whose sha1 hash starts with say 32 bits of zeros (and record >those to avoid reuse). I like the idea of requiring combinations of scarce resources. It's definitely on the wishlist for future releases. Captchas could be integrated as well. >2. The token reuse detection in signcert.cgi is flawed. Leading zeros >can be added to r which will cause it to miss the saved value in the >database, while still producing the same rbinary value and so allowing >a token to be reused arbitrarily many times. Thanks for pointing that out! Shouldn't be hard to fix. >3. signer.cgi attempts to test that the value being signed is > 2^512. >This test is ineffective because the client is blinding his values. He >can get a signature on, say, the value 2, and you can't stop him. > >4. Your token construction, sign(sha1(r)), is weak. sha1(r) is only >160 bits which could allow a smooth-value attack. This involves >getting signatures on all the small primes up to some limit k, then >looking for an r such that sha1(r) factors over those small primes >(i.e. is k-smooth). For k = 2^14 this requires getting less than 2000 >signatures on small primes, and then approximately one in 2^40 160-bit >values will be smooth. With a few thousand more signatures the work >value drops even lower. Oh, I think I see. The k-smooth sha1(r) values then become "bonus" tokens, so we use a large enough h() that the result is too hard to factor (or, I suppose we could make the client present properly PKCS padded preimages). I'll do some more reading, but I think that makes sense. Thanks! -J ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.leitl.org 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: [tor-talk] Tor banned in Pakistan.
by Anthony G. Basile 06 Jul '18

06 Jul '18

On 09/08/2011 05:23 PM, Matthew wrote: > > http://www.guardian.co.uk/world/2011/aug/30/pakistan-bans-encryption-softwa… > > Very disturbing. I wonder if its possible to hide encrypted traffic as seemingly unencrypted http traffic in much the same way as a gpg key is rendered as ascii armored, or stenographically inside images. Although such methods may be inefficient, they may be good enough for some purposes. It would be good to know what technologies these ISPs will implement to do the packet inspection for encrypted tunnels. Half the problem is you don't really know what they'll be looking for and so you don't know how to circumvent. -- Anthony G. Basile, Ph. D. Chair of Information Technology D'Youville College Buffalo, NY 14201 (716) 829-8197 _______________________________________________ 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

Re: [tahoe-dev] switching from introducers to gossip?
by Brian 06 Jul '18

06 Jul '18

On 7/3/12 3:51 AM, darrob wrote: > We've been using the multi-introducer patch on I2P since Tahoe-LAFS > 1.8.3 and it has indeed proven to be more robust. The > single-introducer grid we started out with simply fell apart when the > introducer disappeared. It then took a long time before everybody > learned the new introducer's address and adjusted their > configurations. Time and files were lost. This hasn't happened again > since we've started using the patched version. > > The administrative burden is definitely there. However, I'd argue > against it being worse. At least nodes that only know about a subset > of introducers (e.g. only I2 in your example below) are in no rush of > adding the rest (I3) because the grid is still functional. Ah, that's an excellent data point. Thanks! Yeah, multi-introducers are a bit like RAID: you have more time to respond to a failure before the whole system starts having problems. >> If you generalize this, then all nodes can function as introducers, >> and there's no need for dedicated Introducer nodes. As long as at >> least one node with a public IP is up at any given time, everybody >> else can learn the current state of the world. > > This sounds perfect. I wonder if this system is susceptible to > introducer spam attacks of some sort, though. I image those would be > an annoyance at best. Yeah, I think the worst-case attack is a DoS, where somebody floods useless information into the system. The key is the signed announcements: you may hear about all sorts of garbage, but you'll only pay attention to announcements that are signed by someone you've Invited, or who Invited you, or to whom you're transitively connected by Invitations. Ideally we can use that same criteria to limit how Announcements are flooded, so unrecognized garbage (i.e. "a stranger") doesn't travel further than a single node. cheers, -Brian _______________________________________________ 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