July 2018 - cypherpunks-legacy

[Freedombox-discuss] Half a bag of chocolate for the FreedomBox!
by Markus Sabadello 06 Jul '18

06 Jul '18

Hello, I have recently been to 2 conferences where I talked about the FreedomBox. * European Identity Conference (EIC): I was in a workshop about "Life Management Platforms", and I explained the FreedomBox concept to the audience. This was a very corporate kind of conference, but guess what, there was actually a lot of talk about decentralization! See my blog post here<http://blog.projectdanube.org/2012/04/freedombox-at-the-european-identity-c…> . * Internet Identity Workshop (IIW): I brought 4 Guruplugs and did a demo of what a FreedomBox COULD enable. See my blog post here<http://blog.projectdanube.org/2012/05/freedombox-at-the-internet-identity-w…> for a description and some screenshots of the demo. At IIW, it is customary that at the end of each day, participants award each other wine and chocolate for special achievements. And well, I got (half) a bag of chocolate for the FreedomBox demo. At the two events, I mentioned consistently that I am not speaking for FreedomBox "officially", but that I had been observing it for a while. I'd really love to get more closely involved, perhaps I could even make it to the June Hackfest (but it's a long and expensive flight, don't know). Specifically, I'd like to do the following: 1. Start a discussion on how the FreedomBox could fit into some communities I am in touch with, especially the Personal Data Ecosystem<http://personaldataecosystem.org/> (PDE) and Vendor Relationship Management<http://blogs.law.harvard.edu/vrm/> (VRM). PDE is about giving individuals control over their personal data. Uhm, it's also about new business opportunities, something like a "fair trade for data". VRM is about giving you the means to manage your relationships with the vendors/suppliers you deal with in your life. 2. On the technical side, figure out the path to building the custom demo software from IIW on top of the existing FreedomBox stack, i.e. integrate it with Plinth, Santiago, etc. Find attached the chocolate :) Markus -- Project Danube: http://projectdanube.org Personal Data Ecosystem Consortium: http://personaldataecosystem.org/ _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- 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: Is the Wikileaks Party a cypherpunk party?
by CryptoFreak 06 Jul '18

06 Jul '18

On 08/21/2013 09:04 AM, Eugen Leitl wrote: > On Sat, Aug 17, 2013 at 05:01:07AM -0500, CryptoFreak wrote: > >>> So what do you think? Is their finally a political party more >>> closely aligned with the cypherpunk ideal than the Libertarians? > >> Don't forget the Pirate Parties. Despite all the fubars, >> the German Pirate Party is expected to hit 3+% in the >> national elections next months. >I've looked into the Pirate Party but, at least from the American side >of things, they seem like a 'one hit wonder' who's nearly solely focused >on IP law reform. Perhaps this isn't the same in other places (I can't >imagine they would have won major elections with a single issue >platform) but here in the States, where they exist, it seems to be the case. In a winner-take-all system like the US, third parties are irrelevant, except insofar as they (like Bernie Sanders) caucus with one of the duopoly. Birgitta Jonsdottir gets good press as a PP member of the Icelandic Parliament. FOr what that's worth.

1 0

The Word Spy for 08/28/2003 -- darknet
by Paul McFedries 06 Jul '18

06 Jul '18

darknet n. The collection of networks and other technologies that enable people to illegally share copyrighted digital files with little or no fear of detection. Also: Darknet. Example Citation --------------------------------- Here is a prediction: the darknet will never die. Adversaries will send out their digital agents to hunt down its disciples. But the darknet will go further underground, finding new ways to escape the reach of these electronic attackers. The faithful will find safety by banding together in small groups, beyond the reach of the oppressors. The script for the next Matrix sequel? No -- because the darknet is already here: it is the unofficial side of the internet. And its resilience guarantees that it will remain a thorn in the side of the music and movie industries, whatever successes they may have in crushing its early manifestations. --Richard Waters, "No respite from the forces of darknet," Financial Times (London), July 29, 2003 Backgrounder --------------------------------- The ominous tone that pervades the word "darknet" is probably no accident. That's because the joint coiners of the term -- Peter Biddle, Paul England, Marcus Peinado, and Bryan Willman -- are employees of Microsoft, a company on the forefront of something called digital rights management. DRM is a set of technologies that aims not just to ensure that people pay for copyrighted digital content, but also that they can't make illegal copies of that content. In a paper called "The Darknet and the Future of Content Distribution" (see http://crypto.stanford.edu/DRM2002/darknet5.doc) the above authors argue that the existence of the darknet severely undermines all DRM initiatives, which is dark news indeed for Microsoft and every other company that hopes to control the use and abuse of copyrighted digital files. Earliest Citation --------------------------------- "Users will copy objects if it is possible and interesting to do so," said authors Peter Biddle, Paul England, Marcus Peinado and Bryan Willman. That truism, they said, when combined with a high-bandwidth network and only a fraction of users initially sharing content, made the darknet ubiquitous. Sharing has existed for years, they argued, but the "sneaker net" approach of mixed cassette tapes passed among friends or sent through the mail meant the copyright abuse was "trivial." --Patrick Ross, "Microsoft Employees Write That DRM Systems Is Doomed to Fail," Washington Internet Daily, November 25, 2002 First Use --------------------------------- We investigate the darknet -- a collection of networks and technologies used to share digital content. The darknet is not a separate physical network but an application and protocol layer riding on existing networks. Examples of darknets are peer-to-peer file sharing, CD and DVD copying, and key or password sharing on email and newsgroups. The last few years have seen vast increases in the darknetms aggregate bandwidth, reliability, usability, size of shared library, and availability of search engines. In this paper we categorize and analyze existing and future darknets, from both the technical and legal perspectives. We speculate that there will be short-term impediments to the effectiveness of the darknet as a distribution mechanism, but ultimately the darknet-genie will not be put back into the bottle. --Peter Biddle, Paul England, Marcus Peinado, and Bryan Willman, "The Darknet and the Future of Content Distribution," Digital Rights Management conference, November 22, 2002 See Also --------------------------------- bitlegging: http://www.wordspy.com/words/bitlegging.asp burn and return: http://www.wordspy.com/words/burnandreturn.asp cuckoo egg: http://www.wordspy.com/words/cuckooegg.asp digifeiter: http://www.wordspy.com/words/digifeiter.asp IP thief: http://www.wordspy.com/words/IPthief.asp Napster bomb: http://www.wordspy.com/words/Napsterbomb.asp P2P: http://www.wordspy.com/words/P2P.asp Subject Categories --------------------------------- Computers - Data: http://www.wordspy.com/index/Computers-Data.asp Computers - Internet: http://www.wordspy.com/index/Computers-Internet.asp Computers - Networking: http://www.wordspy.com/index/Computers-Networking.asp Computers - Programming and Software: http://www.wordspy.com/index/Computers-ProgrammingandSoftware.asp Words About Words --------------------------------- The best craftsman always leaves holes and gaps in the works of the poem so that something that is not in the poem can creep, crawl, flash, or thunder in. The joy and function of poetry is, and was, the celebration of man, which is also the celebration of God. --Dylan Thomas, Welsh poet, short-story writer, and playwright, "Poetic Manifesto" in the _Texas Quarterly_, Winter 1961 Miscellanea --------------------------------- The WordSpy mailing list is available in an HTML version that bears an uncanny resemblance to the pages on the Word Spy Web site (see the address below). If you'd like to try it out, send a note to listmanager(a)logophilia.com and include only the command "html wordspy" (without the quotation marks) in the Subject line. For more Word Spy words, see the Word Spy Archives: http://www.wordspy.com/ You are currently subscribed as rah(a)shipwright.com. To drop this address from the list, you have two choices: Send a message to listmanager(a)logophilia.com and include only the command "leave wordspy" (without the quotation marks) in the Subject line. Or, Use the following Web address: http://www.wordspy.com/list/remove.asp?Email=rah@shipwright.com&ID=26169 ======================================================== --- end forwarded text -- ----------------- R. A. Hettinga <mailto: rah(a)ibuc.com> The Internet Bearer Underwriting Corporation <http://www.ibuc.com/> 44 Farquhar Street, Boston, MA 02131 USA "... however it may deserve respect for its usefulness and antiquity, [predicting the end of the world] has not been found agreeable to experience." -- Edward Gibbon, 'Decline and Fall of the Roman Empire'

1 0

Free Certificate Authority Unveiled by Aussies
by brian-slashdotnews＠hyperreal.org 06 Jul '18

06 Jul '18

Link: http://slashdot.org/article.pl?sid=04/07/02/0116236 Posted by: CowboyNeal, on 2004-07-02 04:21:00 Topic: privacy, 124 comments from the good-things-from-down-under dept. [1]SonOfGates writes "Well, the Aussies have invaded Boston but at least they're not throwing tea into the harbor. AU-based nonprofit [2]CAcert Inc has spent the last few days at [3]USENIX '04 registering new users by the truckload. They bill themselves as a 'Community-Based CA.' Could this be the begining of a true 'open' certificate authority? See the [4]O'Reilly story and [5]press release." IFRAME: [6]pos6 References 1. http://www.cacert.org/ 2. http://www.cacert.org/ 3. http://www.usenix.org/ 4. http://www.onlamp.com/pub/wlg/5142 5. http://www.cacert.org/media/boston1.pdf 6. http://ads.osdn.com/?ad_id=2936&alloc_id=8587&site_id=1&request_id=2048979 ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> ______________________________________________________________ ICBM: 48.07078, 11.61144 http://www.leitl.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE http://moleculardevices.org http://nanomachines.net [demime 1.01d removed an attachment of type application/pgp-signature]

1 0

[Politech] NSA surveillance: EFF lawsuit; new white paper by ACLU
by Declan McCullagh 06 Jul '18

06 Jul '18

EFF has sued AT&T over its alleged participation in the NSA's surveillance scheme: http://news.com.com/2100-1028_3-6033501.html Complaint: http://www.eff.org/legal/cases/att/att-complaint.pdf BTW I think the ACLU's map (below) is intended to be more fanciful than based on any confirmed participation by U.S. telecom or Internet companies. The closest we've come to actual confirmation was a paragraph buried in the middle of a Los Angeles Times article last month about AT&T, mirrored here and cited in the EFF suit: http://www.libertypost.org/cgi-bin/readart.cgi?ArtNum=122448 Am I missing something? -Declan -------- Original Message -------- Subject: New NSA Spying Map and White Paper Date: Tue, 31 Jan 2006 17:03:56 -0500 From: Barry Steinhardt <bsteinhardt(a)aclu.org> To: declan(a)well.com Declan, Politechicals may be interested in a new ACLU white paper and interactive map detailing what is known and suspected about how the NSA's illegal spying on Americans occurs and where the interceptions are likely taking place.. The white paper is entitled "Eavesdropping 101: What Can the NSA Do?" It looks at the probable connections that the NSA has made to the U.S. civilian communications infrastructure. The map shows how the NSA's "surveillance octopus" likely entangles the country. We believe it is the first effort to visually illustrate what is happening. You can find both the white paper and the map at <http://www.aclu.org/safefree/nsaspying/23989res20060131.html>http://www.aclu .org/safefree/nsaspying/23989res20060131.html>http://www.aclu.org/safefree/ns aspying/23989res20060131.html. A complete range of materials can be found at www.nsawatch.org. Barry Steinhardt Director Technology and Liberty Project American Civil Liberties Union (ACLU) _______________________________________________ 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

Geurilla open access cookbook
by Bryan Bishop 06 Jul '18

06 Jul '18

Open access guerilla cookbook https://github.com/c0nt3nt/oagcookbook https://github.com/c0nt3nt/oagcookbook/blob/master/oagcb.md git clone git://github.com/c0nt3nt/oagcookbook.git """ The Open Access Guerilla Cookbook =============================== Dedicated to Aaron Swartz (1986-2013) Introduction ---------------- In 2008, a short and passionate appeal appeared online which called for all of us to, "take information, wherever it is stored, make our copies and share them with the world. We need to take stuff that's out of copyright and add it to the archive. We need to buy secret databases and put them on the Web. We need to download scientific journals and upload them to file sharing networks. We need to fight for Guerilla Open Access." In January, 2013, its author Aaron Swartz took his own life. Among his many achievements included an important initiative to liberate the PACER court records database and leadership roles in several movements that support free culture. In the last years of his life, he faced serious criminal charges for following his own manifesto and launching one of the largest content liberation efforts to date: the downloading of millions of articles from the JSTOR database. If the threat of decades of prison time for the JSTOR raid was designed to strike fear into OA guerillas everywhere, the tragic death of this selfless supporter of the movement should be met with a renewed commitment to our ideals. It also offers us an opportunity to up our game. This document aims to take the manifesto to the next step. This first version is merely an opening call, and it is in no way complete. Hopefully, this cookbook will grow to include many recipes and instructional essays for use by the open access guerilla. Improve on it, share it, and use it. Principles ------------- The guerilla open access movement is founded on the basic tenant that the efforts to promote open access by operating exclusively within existing copyright regimes and attempts to reform these copyright regimes through legal reform do not go far enough to protect and expand the realm of free culture. Working in parallel, but often in the face of criticism from those promoting legal means to achieve open access, our guerilla movement accepts the active violation of copyrights and contractual terms of use as justified. We promote the mass liberation of content from commercial as well as non-profit or governmental databases for the greater purpose of sharing knowledge and culture with everyone. We are closely allied with movements promoting government and corporate transparency, but open access guerillas recognize that there is responsibility in sharing information. When relevant, precautions should be taken to defend the safety and privacy of individuals and communities in appropriate ways. We are pirates, but accept a moral imperative to loot more than we need for our own purposes, and share widely everything we find. We categorically reject descriptions of our acts as theft. We do not deprive humanity of culture, we reproduce it. We do not rob owners of their property, but in many cases violate their temporary and exclusive monopoly to profit by it in an age when the reasonable limits first set upon this monopoly have been long forgotten. We violate crippling terms of use on content in an age when access to almost all information requires accepting contractual limitations that few ever read. We re-release materials that are already in the public domain but locked behind paywalls or targetted by copyfraud. Looking forward, the strength of the guerilla open access movement depends on combining efforts both secret and open, both collaborative and individual. We must: **Share skills and experiences as well as content** Content liberation should not solely depend on a few individuals with highly technical knowledge. We must work harder to share our skills and our experiences widely. This should include efforts to better reach out to those who are new but eager to learn the more challenging technical side of our guerilla efforts. We should also work towards establishing standards in the quality of our content collections, security practices to protect our illegal efforts, and a code of ethics for operating with the content sources we raid. **Recognize a diversity of roles and a diversity of approaches** We must abandon the image of the lone hacker as the symbol of our movement and recognize that any successful guerilla movement depends on the work of people filling many different roles. Some of these are described below. We are radical in our means, dedicated to our ideals, and will be reviled and ridiculed by many. Many with similar goals to our own reject us, but they should still be considered as allies. Our movement exists within an ecology of culture creation, curation, and consumption. We must respect everyone who plays a role in the interdependent whole, even as we oppose the legal regime under which they operate. There are many artists, writers, scholars, archivists, librarians, developers, and non-profit organizations who strongly oppose us. They argue that their livelihoods are threatened by our actions, while others secretely sympathize with us. Let us be mature enough to admit that some of our targets produced their collections of content with little funding, charge their access fees with no mind to profit themselves, and host servers with a barebones maintenance staff. When we liberate their content, or share with others, keep always in mind the work that was put into creating and publishing it. Show as much respect as is compatible with our goals and remember that we are nothing without them. **Collaborate to reduce risk and maximize scale** We now live in the world of crowdsourcing. The power of a lone hacker armed with a scraper and some knowledge of security is not to be underestimated, but it comes at great risk of discovery and sacrifice. We must explore ways to better combine our efforts. The RECAP effort for the PACER archive of court documents is one model of how this approach works within the legal realm, we can learn from it and others. We should develop the means to conceal systematic content liberation in the invisible mass of everyday consumption. Rather than grabbing whole archives and document databases at once, we should take them in smaller pieces, with care to preserve their metadata integrity, and plans in place to reassemble the whole when an operation is complete. **Segregate open from secret action** Aaron Swartz combined strong public advocacy with secret guerilla action. In his case, it was not key to his discovery, but it is likely to have impacted the severity of the charges brought against him. In all guerilla movements it is important to segregate open from secret action. It is unwise to be an open voice for radical illegal action and also its agent. If you begin engaging in dangerous OA guerilla action, temper your public voice and avoid drawing attention to yourself, especially with regard to the virtues of illegal content liberation. **Protect the Public Domain First** Almost none of us are against the principle of limited terms of copyright as a way to promote the long term expansion of the public domain. The passion that drives most us to these radical measures would not exist in a world with copyright terms of ten or fifteen years. At this writing, there are very few signs that legal reforms will move us back to these limits, and on the contrary, in many places around the world the trend is in the opposite direction. More threatening, however, is the assault upon what is already in the public domain. In acts of copyfraud, publishers and digital service providers claim rights on content they do not own. They claim that new rights are produced in their digitization and, increasingly, they are moving away from copyright to contractual terms of use to limit our freedom to use public domain materials obtained from their databases. The ever increasing proportion of our cultural heritage bound by these contractual restrictions will have direct consequences. The trend significantly drains support for initiatives to create fully open and free databases of materials that may already have been made available by more restrictive ventures, whether they are commercial or non-profit. For these reasons, our movement's priority should be on the liberation of content in the public domain followed by those materials that, by any just limited term of copyright, should have in the public domain decades ago. Roles in the Movement ----------------------------- There are many ways to further the goals of the guerilla open access movement. Find one or several of the following roles that you feel comfortable performing. **The Advocate** The advocate promotes the cause of open access. Many OA and copyright reform advocates believe we rob their efforts of legitimacy by making it easier for content industries to smear them with our sins. Others believe, on principal, that OA must depend always on voluntary sharing. As one leader in the legal OA movement puts it, "There is no vigilante OA, no infringing, expropriating, or piratical OA." We disagree. We believe our efforts usually compliment those of the leading proponents of free culture and copyright reform. We do not accept that it is a zero sum game in which the efforts of one destroys that of the other. However, if you wish to focus on the role of a public advocate, it would be prudent to join them in their open rejection of our methods and limit any other guerilla activities. Another kind of advocate is less public: to promote guerilla OA as well as legal OA among your friends, colleagues, and those who have the skills to be of use to the movement. Of particular importance are efforts to convert the casual pirate into the open access guerilla; from someone who copies content only for their own consumption to someone who recognizes the value of a more active and altruistic participation in the movement. **The Prospector** The role of Prospector is that of the scout for the movement. A Prospector identifies databases or collections of interest to the movement and collects information about its workings. What kind and how much content is there? How is it organized? What metadata is provided? What is the URL structure for the database? What is required for access and who provides the service? And so on. We need to design a good system for compiling and sharing information of this nature among us, so that that the Armoror, the Sapper, or the Traitor can do their work. **The Scribe** The Scribe is a unique role. Scholars and collectors of all kinds have massive collections of material obtained by photographing, scanning, or transcribing documents or assembling other digital assets. The resulting digitized content often sits on their own hard drives and are used in only one or a few publications or exhibits. A Scribe in the movement is conscious of the importance of their videos, images, sounds, and digital archive photos. When reasonable, the Scribe collects or takes photos that go beyond their own limited interest, or transcribes or indexes materials that may be of interest to others. They organize their information to the extent possible and make efforts to share their files widely. Materials not protected by copyright are to made public, directly posted online as public domain. When materials are suspected of being protected by copyright, they are distributed through other means or deposited with a Custodian. The Scribe is one of the roles that must take particular note of the responsibilities that go along with the safety and privacy of individuals and communities affected by the contents of the materials they digitize. To facilitate the full integration of the Scribe into the movement, we must work towards better systems of making these collections easy to share, and a standard for describing and organizing them. **The Courier** The Courier is usually someone who has received collections of materials from another OA guerilla. They do not merely use the materials themselves, but recognize their obligation to help further share and distribute the materials widely. While taking measures to protect themselves, the Courier makes efforts to share the materials online through torrents or other private repositories and servers, possibly coordinating these efforts with a Custodian. They share copies of the collections on portable storage media throughout their personal networks. Another form of Courier plays the role of communication mediater between guerillas that should work to be kept in isolation from eachother, such as between the Traitor and Prospector and the Armorer. **The Innkeeper** The role of the Innkeeper is to manage the safe houses of our movement. We need safe and secure places to communicate with eachother anonymously. Ideally, these places should be kept isolated from any servers operated by the Custodian so that discovery of one does not compromise the other. The Innkeeper may be willing to host the work produced by the Armorer, various versions and updates of this cookbook, and other instructional materials. An Innkeeper must be willing to maintain a communication network that will likely come under attack from hired hackers, botnets, or directly by principled opponents. They must have precautions in place to destroy anything that might betray the identity of our members. They should have plans to rapidly reproduce the network at a new location when taken down. They must lead efforts to detect moles and informants within the network and deny them access. **The Armorer** The Armorer is one of the most important roles in our movement. They create, maintain, and supply our movement with the weapons we need to carry out our raids. They write and update the scrapers to liberate content. They create the processing scripts to organize our files, and they design the protective measures that conceal our efforts. In the past, the open access guerilla has often been an Armorer, a Traitor, and Custodian all in one. One huge disadvantage to this is that the Armorer who is also the Traitor cannot easily share their tools without potentially coming under scrutiny for launching raids themselves. If discovered, as Custodian, their liberated materials are potentially surrendered and lost. We must work together. If an armorer works together with Prospectors to identify targets and design scrapers, but maintains some distance from (or at least communicates anonymously with) the Traitors who will deploy them, we will stand a better chance of a successful operation. The Armorer may choose to work openly, if they protect connections to others in the movement. Writing a scraper is not necessarily a crime, but it is strongly suggested that efforts are made to limit distribution to a trusted network, at least until an operation is complete. This will delay any countermeasures by content distributors. More broadly, however, Armorers should be willing to share, through work such as adding recipes to this document, tutorials on general approaches to scraping databases and archives. **The Sapper** The Sapper is a special kind of Armorer. The Armorer serves primarily the Traitor, who will deploy scrapers from within a paywall or behind restrictive terms of service. The Sapper explores ways to infiltrate the security of archives and databases and enable outsiders direct access. They may hack servers directly in order to enable a full and immediate grab of the databases within. They may create access tunnels for a more cautious silent raid from the outside. Or, in the most extreme case, they may bring about a temporary destruction of security to allow large numbers of users to storm the database in a mass action. The role of Sapper requires the greatest amount of skill and assumes the greatest amount of risk, both to the Sapper and the movement as a whole. Sappers should carefully consider the consequences of their actions and the impact on the ecology of content creation, curation, and consumption. A Sapper's raid, depending on how it is carried out, can be a massive act of sabotage, and has the greatest potential to generate anger and fear from our opponents but also put pressure on our sympathizers. Use of it as a tactic should be carefully considered, and great care taken in selecting the target, the timing, and the approach. **The Traitor** The Traitor is at the heart of the content liberation effort. They have legitimate and legal access to content targetted for liberation and release what they take to the Custodians and Couriers. They often depend on their special access to carry out their own daily tasks, and beyond legal consequences, may sacrifice much if their actions are discovered and their access revoked. Beyond this risk, the traitor often has conflicted loyalties. They have received their access in trust, and by helping the guerilla open access movement, they are inevitably betraying that trust. The Traitor may know especially well the great efforts required to fund, produce, curate, and host large collections of data. Even as they liberate content, they may be concerned that their actions will contravene the wishes and have some impact on people who may have only very reluctantly accepted the restrictive copyrights and terms of use that have been forced upon the product of their efforts by the institutions they serve. If you work with a Traitor, be sensitive to these concerns, and respectful of what may seem like arbitrary limitations they wish to place on the scale and nature of their cooperation with the movement. As the one opening the gate, the risky work of the Traitor should ideally be carried out in total secrecy. They should communicate securely and anonymously with other members of the movement, and limit their other roles. They do not need the Armorer's technical skills if they can obtain (indirectly, through a Courier, or directly and anonymously from a movement resource) the necessary scrapers and other tools produced by the Armorers. It is important, however, for them to become familiar with security measures to protect their identity and conceal their liberation efforts. They should also learn enough about the scrapers etc. that they use so that they can run them on their own computers and adhere to the basic scraper guidelines (below). **The Custodian** Traitors or Sappers who have liberated content should move as quickly as possible to deposit this content with Custodians. The role of the Custodian is first and foremost that of canonical preservation. They also play an important role as the primary distributor of content to Couriers. They should also keep themselves informed about the safest and most effective means to widely distribute content on file sharing networks, secret repositories, and by other means. When hosts have been raided; copies of content have been taken down by legal authorities; or hosted copies disappear through neglect (lack of seeders for torrents, etc.), it is the job of Custodians to take measures to get the content to new sources. Whenever possible the Custodian should check that the collections they received to not bear traces of the origin, looking for signs of watermarked PDFs, scraper files with revealing login information, or other signs that would reveal the identity of the guerilla who liberated the content. Custodians should take precautions against their own discovery, and arrange for copies of materials in their care to be deposited in a safe place should they be discovered. They should also ideally limit actions in other roles of the movement to limit the risk of exposure. **The Archivist** The role of the Archivist is to preserve and improve the integrity of liberated content. They identify missing or problematic metadata, they process and organize files, and potentially provide conversions of problematic formats that materials are found in. If independent operations liberate parts of collections, the Archivist can help bring them together. They create note documents to include in the distribution of liberated content which describes the scope of the collection, identifies problems in the material, provides information on the originating source, and suggests ways to cite it. They collaborate with Prospectors to identify further work that needs to be done on already raided collections, and with Custodians to spread the best possible version of a collection. Archivists with strong digital skills can also create the tools and platforms, both local and hosted, that will allow users to conveniently search and browse liberated content. A zip file full of PDFs or movie files is an order of magnitute less useful than a collection which is well indexed, annotated, and conveniently searchable. **The Sculptor** The Sculptor is someone who is willing to use and create something new with liberated content. They analyze and study collections for use in their own work. They produce new works of art and culture. They remash, reproduce, and transform liberated content. They generate innovative ways for others to manipulate and use content. Ideally we should all be Sculptors. The value of the guerilla open access movement comes from facilitating the Sculptors of today, tomorrow, and every day that content would otherwise be locked away behind copyright and restricted use. Scraper Guidelines ------------------------------ Scrapers are scripts designed to selectively extract content from servers. They are often written in scripting languages such as Python, Ruby, or Perl that can be run from a variety of operating systems. They are one of the most powerful tools of the guerilla open access movement. When scrapers or other raiding tools are designed by the Armorer and deployed by the Traitor, the two general principles of *respect* and *concealment* should be followed. For this purpose keep these guidelines in mind: 1. Minimize disruption to the host and their other users by 2. Limiting the scale and speed of a raid appropriately and 3. Employing methods to mask your raid as reasonable use of the target resource More specifically: - Never attempt to grab an entire database in the space of hours or over a very short time span relative to its total size - Generally limit the practice of multiple simultaneous downloads from a server. - If a small number of simultaneous downloads are made, carry it out from multiple network locations and ideally with multiple access credentials. - Do not place others at risk by using their network access credentials unless they understand the potential consequences and volunteer. - Employ proxies, MAC spoofing, and other measures as needed to conceal access locations when this is possible. - Use random intervals between downloads to simulate human behavior - Limit the operation of scrapers to certain hours to simulate human behavior or bury activity in periods of large regular traffic - Design scrapers to download materials randomly (while logging completed downloads) rather than in sequence, or else a random groups of smaller sequences consistent with human behavior **Recipes** ----------------- The remainder of this cookbook should be composed of recipes. These may include instructions for the use of or the code for scrapers and other tools that are appropriate for wider distribution. They may include tutorials and descriptions of good practices for the various roles of the movement. They may describe appropriate security measures. They may recount past victories and failures of the movementbbut in a way that does not compromise anyone's identity. They should ideally not include any direct links to online resources, but may provide suggestions on how to use search techniques to find them, as they may often move. Under each recipe, include the date it was written, an optional author pseudonym, and if you distribute an edited version of this document, update the timestamp and version information at the bottom for the cookbook as a whole. Securing Communication -------------------------------- By yellowElephant Security in communication between members of the movement is of great importance. While legal authorities will want to investigate our actions, perhaps of a greater threat is that publishers and content industries that have significant resources will want to undercover who we are and can easily outsource their work to hired hackers. It is important to follow some basic guidelines that can be grouped as follows: 1. Create barriers of separation between your regular activity and movement activity 2. Mask your identity 3. Mask your location 4. Encrypt your information 5. Limited Circles of Trust **Separate your Movement Activity** The first principle is a general one that you should always keep in mind. Whenever possible, create a separate sphere for all things concerned with your activity in the movement. Some of these things are just common sense. If you email about the movement, do so from a separate email account, not your regular personal email account. If you tweet about the movement, then unless you are only an Advocate who is not connected with illegal operations of the movement, tweet from a separate account. If you write about the movement on a website or other online service (again unless you are only an Advocate) then do so from accounts set up for the purpose. If you need to set up online service accounts that require email verification use email addresses that come from an online email service which does not require you to provide further means of identification. This secures your anonymity as long as you mask your location. When you are working on something related to the movement, even if you have masked your location, avoid doing other things online that may associate your IP address with other activity online and thus make it possible to trace back to you. Consider using a different browser for all your movement activity. Or, at the very least, use "privacy" or "secure" or "icognito" mode in your browser. This will prevent your browsing history from being saved. More importantly it will prevent cookies from operation. If you are logged into a social networking service and then start doing movement activity without this layer of security in another tab or window, the website you are using may have ways to identify you through cookies. **Mask Your Identity** If you are a Courier or an Advocate, what you write and do will be exposed to the scrutiny of those outside the movement. Adopt a code name, but be sure to choose one that cannot be associated with you, even by friends. Thus, if you are a famous dog trainer, don't choose a code name of a breed of dog. What you write can be subject to automatic text analysis. Authorship can be compared by means of algorithms. Try to vary your writing style. Make a list of idiosyncratic adjectives or other turns of phrase that you only use in some texts you write but not others. Write verbosely in some places, and in a short blunt manner in another. Use leet speak in some contexts, and grammatically correct language elsewhere. If you are exposed, this will help prevent you from being associated with all of your activity. **Mask Your Location** This is very important. Do not engage in movement activity from your own IP address (your identifying address on the internet) and spoof your MAC (the hardware address on your network or wireless card). If you are connected to a University of Vienna computer network, and you do anything online without masking your location, it is easy to trace the activity back to the university network, which will likely have a log of who is registered to use the IP, or at least the rough physical location that the person connected from. From there it is either direct discovery or discovery with subsequent surveillance. *Mask your IP* Use a free or paid VPN (virtual private network) service that cannot be traced back to you personally. Make sure to configure it so that all traffic to and from your computer is routed through this VPN. Connected to a VPN in Russia, a user on the network in Vienna will appear to be connecting from Russia. *Spoof your MAC* This is easily done with a little bit of experience on the command line. There are many utilities that can help you do this on Windows. On Linux or OS X simply open a terminal and enter the appropriate command that you can find many places online. *Fool Your Enemy* If, as a Courier for example, you engage in movement activity that may give indirect hints about your geographical location, then cloud their view. If you have a twitter account and are based in Canada, follow a set of users that might imply you are in France and read French. If you are emailing users in the UK, consider doing it from a free email service based in Germany. **Encrypt Your Communication** All movement related activity through email and chat should be secure or anonymous and generally both. *Email and General Encryption* Learn about GnuPG and the basics of public-private key encryption. Create an encryption key for yourself. Make sure the passphrase is very long. "The yellow elephant flew effortlessly behind the old barn" is far more secure than "&%tX90!" and easier to remember. Export the public key as ASCII armored and give it to your movement contacts. They will use *your* public key to encrypt email they send to you. You will use *your* corresponding secret key to decrypt the email they sent you that was encrypted by *your* public key. The process is reversed when you email them. You will need *their* public key to email them. Sign your communications with your key to help confirm your identity. *Secure Chat* Consider using anonymous communication on a pre-agreed IRC chat for something that is simple and fast and can be performed directly in your (secure/icognito) browser (while connected to VPN). There are also many plug-ins to secure communication on popular chat protocols, as well as some dedicated secure chat clients. Make sure that neither you nor the person you are speaking with have the client configured to log the communication. *Keep Movement Related Files Secure* If you are apprehended all your computers will be taken. You cannot be coerced into providing passwords though, so if you are smart, you will keep movement files completely secure. You can encrypt your files and directories directly with GnuPG. Another common method is to create an ecrypted partition or "disk image" that is encrypted. Boot this partition or disk image when you need access to your movement files. Or have a separate encrypted hard drive that you load when you are ready to do work for the movement. **Limited Circles of Trust** Do not tell all your cool friends that you are active in the movement. Limit this information to people you trust *and* who you believe can be recruited to active participation in the movement. Whenever possible, maintain a segregated guerilla cell structure that the movement has operated under up until now. If you recruit several people to work with you do not pass on information about their identity or contact info to the person who recruited you. If you have contact with Couriers, let your up-contact know of their existence so tasks to/from Courier can be transmitted via you. One exception are competent Armorers. Their skills are in high demand, and if you find them, consider keeping them separate from your own cell and "passing them up" the chain to the person who connected you put them in contact with an Armorer or Innkeeper you know of. The scripts/tools they create should be distributed through the network securely and then at some point appropriate openly. As far as this author is aware, we have no centralized structure. We operate in loose and a cell based movement, with anonymous cross-cell communication in online forums and chat maintained by admins (Innkeepers) who don't usually know the identity of anyone on the platforms they manage. Knowledge of personal real identities should, whenever possible, *not* be available beyond the individual cell. Traitors (and the more rare Sapper) are to be protected at all costs since they are directly liable for legal prosectution. If there are people who you personally know but do not trust, yet who you think can be recruited, use a Courier as an intermediary. The Courier establishes contact, and if it goes well, they can "hand back" or "pass on" the contact once secure anonymous means of communication have been established and a role identified. Cells that personally know eachother should take steps to ensure that keys were exchanged in a way to guarantee their genuine nature. Limiting the circle of trust is key to the survival of the movment. In the past, many online hacker networks have been broken when one member is discovered and agrees to cooperate in exchange for a lighter sentence. A previously trusted person will unwillingly do all they can to expose other cell members and escape their own punishment. Be suspicious of suddent attempts to get more personal information from you by contacts in the movement and again, by keeping the circle of trust small, damage can be contained. Ways to Make Your Scrapers More Human ----------------------------------------------------- Below are some simple code snippets to give you ideas about how to design scrapers that will behave more like humans, thus concealing to some degree your raid on a database. Of course, if you conduct the entire raid from a single IP address, or your are always logging in with the same user credentials, a careful analysis of server logs and traffic can lead to discovery. However, the following may help fool the lazy server administrator who merely glances over access logs from time to time. *In Ruby:* ```ruby # => This method can be used to create some variety in pauses between grabbing files from a server # => and thus simulate human behavior. You set a default break time (here twoseconds, in reality a # => random time of 1-3 seconds) and several more rare longer breaks. You then indicate a probability # => for these other longer breaks to occur. For example, currently there is a 0.2% chance that the # => scraper will take a roughly one hour break, but a 0.5% chance it will take a 30 minute break, # => and so on. def randomBreak() #set the various times for a break: twoseconds=rand(1..3) fifteensec=rand(12..18) onemin=rand(50..70) fivemin=rand(250..350) tenmin=rand(500..700) thirtymin=rand(1600..2000) onehour=rand(3300..3900) #default break time: sleeptime=twoseconds #roll the dice: x=rand(1..1000) #but percentage chance that there is a longer break: if (1..2).member?(x) then sleeptime=onehour end if (3..7).member?(x) then sleeptime=thirtymin end if (8..18).member?(x) then sleeptime=tenmin end if (19..32).member?(x) then sleeptime=fivemin end if (33..50).member?(x) then sleeptime=onemin end if (51..120).member?(x) then sleeptime=fifteensec end puts "Sleeping "+sleeptime.to_s+" seconds." sleep sleeptime end randomBreak() #!/usr/local/bin/ruby # => This method can be used to create some variety in pauses between grabbing files from a server # => This method can be used to force your script to only operate within certain "working hours" # => and thus simulate human behavior. If you have a scraper pulling files 24 hours a day, anyone # => inspecting server logs closely will immediately know automated downloading is happening. # => Use this script to make it at least somewhat more plausible that a very diligent human being # => was downloading files from their favorite database. # => # => Call this method once each time a file has been downloaded completely before proceeding to # => the next round of the loop. Only proceed, if the method returns true. If it is "outside # => working hours" it will return false. You can use a while loop to wait until working hours. # fromgmt - how many hours earlier or later than GMT timezone you wish to operate in def workinghours(fromgmt=0,starthour=9,endhour=17) #The current hour at GMT timezone: currentgmt=Time.new.gmtime.hour currentmin=Time.new.min #The current hour at timezone of desired operation: currenthour=currentgmt+fromgmt if currenthour==24 then currenthour=0 end #we assume here workingg hours do not cross midnight, anyone want to redo the following to #account for that possibility? if currenthour>=starthour && currenthour<=endhour return true end return false end #how we might use this: while !workinghours(fromgmt=1,starthour=1,endhour=11) # wait one minute and check the time again sleep 60 end #!/usr/local/bin/ruby # => This very simple snippet can be used to set a maximum limit on # => the time the script will run. Here again we simulate likely human # => behavior. You can run the script comfortable that it will run # => for a limited time. # maxminutes - The number of minutes you want this script to run maxminutes=120 # for example, 2 hours or 120 minutes starttime=Time.new # OPEN YOUR MAIN LOOP HERE if Time.new-starttime>maxminutes*60 then break # out of your loop and wrap up the script... end #!/usr/local/bin/ruby # => If you use Mechanize in Ruby to do your scraping you can set the "user agent," that is, # => the browser that you are pretending to be when you grab files from the server. You can # => add some noise to your activity by choosing a random user agent each time you use the # => script. def randUserAgent() #returns a random user agent but weighs towards popular browsers #returns a random user agent but weighs towards popular browsers #problem: it doesn't include Chrome or Opera. Sample is for Ruby 1.9, need change for #earlier versions of Ruby. return ["Windows IE 7","Windows IE 7","Windows IE 7","Windows IE 7","Windows IE 6","Windows Mozilla","Windows Mozilla","Windows Mozilla","Windows Mozilla","Mac Safari","Mac FireFox","Mac FireFox","Linux Firefox"].sample end # => ... myparser.user_agent_alias=randUserAgent() ``` Recipe: Overcome Built-In Limit on JSTOR Liberator --------------------------------------------------------------------- By FreeDam | Status: Works as of 2012.1.20 The Aaron Swartz Memorial JSTOR Liberator offers an elegant tool for uploading a single publically viewable JSTOR document to a memorial archive. The tool creates a cookie in your browser when you use it and prevents you from making more than one contribution. Perhaps you want to offer ten PDFs to the memorial? Maybe fifty? To overcome the limit without repeatedly opening a new browser window, we can modify your JSTOR Liberator bookmarklet code slightly: ```javascript javascript:var date=new Date();date.setTime(date.getTime()+(10*24*60*60*1000));var expires = "; expires="+date.toGMTString();document.cookie='jstorLib_count=0;'+expires+'; path=/';(function()%7Bvar%20s%3Ddocument.createElement(%27script%27)%3Bs.type%3D%27text/javascript%27%3Bs.src%3D%27 http://aaronsw.archiveteam.org/js%27%3Bdocument.getElementsByTagName(%27hea… ``` This merely sets the "jstorLib_count" to 0, thus allowing you to make multiple submissions. This client side limit will be replaced by a server based limit at some point, but in the meantime, you can use this modified bookmarklet to make multiple contributions easily. This document is in the public domain. Changes -------------------- 2013.1.13 williwaw - original posted 2013.1.16 yellowElephant - added recommended security precautions for movement members 2013.1.19 kfogel - language 2013.1.19-20 williwaw - ruby.recipe add some ways to simulate human behavior in scraper 2013.1.20 FreeDam - Overcome Built-in limit on JSTOR Liberator """ - Bryan http://heybryan.org/ 1 512 203 0507 -- You received this message because you are subscribed to the Google Groups "science-liberation-front" group. To unsubscribe from this group, send email to science-liberation-front+unsubscribe(a)googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. ----- 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: [cryptography] Intel RNG
by coderman 06 Jul '18

06 Jul '18

On Tue, Jun 19, 2012 at 12:48 AM, Marsh Ray <marsh(a)extendedsubset.com> wrote: >... > Right, 500 MB/s of random numbers out to be enough for anybody. these rates often are not useful. even busy secure web or VPN servers use orders of magnitude less. initialization of full disk crypto across an SSD RAID could consume it, but that's the only "practical" use case i've encountered so far :) that said, a typical host entropy gathering daemon is often insufficient, and even off-die serial bus and other old skewl sources were providing entropy in kbit/sec rates, not MByte/sec. > My main point in running the perf numbers was to figure out the > justification for this RNG not being vulnerable to entropy depletion attacks > in shared hosting environments. some (many?) HWRNG designs use bit accumulators that feed a register that is read by a userspace instruction. consider the following configuration: - this register is collecting single bits from two high speed oscillators that is sub-sampling single bits at a quarter clock. - only whitened / non-run bits collected, as set in a configuration write / initialization. in short: providing slow, non-deterministic output rates to this entropy instruction. if the instruction is configured to not-block, you could starve the available pool in one thread, in one process, by using it aggressively. if the instruction is configured to block, you could introduce significantly processing delays (unexpectedly so?) to other consumers in other threads of execution, or other processes. Intel did an end run around this problem with the DRBG, which is similar to urandom, in the sense that it does not provide a 1:1 correlation of entropy in the system to entropy bits returned out, as you may get in /dev/random linux behavior, which blocks once the kernel entropy pool is exhausted. (that's another rant/tangent. let's not go there :) > Still, 150 clocks is a crazy long time for an instruction that doesn't > involve a cache miss or a TLB flush or the like. >... > So something is causing AES-NI to take 300 clocks/block to run this DRBG. > Again, more than 3x slower than the benchmarks I see for the hardware > primitive. My interpretation is that either RdRand is blocking due to > "entropy depletion", there's some internal data pipe bottleneck, or maybe > some of both. it is also seeding from the physical noise sources, running sanity checks of some type, and then handing over to DRBG. so there is clearly more involved than just a call to AES-NI. 3x as expensive doesn't sound unreasonable if the seeding and validation overhead is significant. > If in reality there's no way RDRAND can ever fail to return 64 bits of > random data, then Intel could document that fact and we could save the world > from yet another untested exceptional code path that only had a moderate > chance of working the first time it's really needed anyway. that's a great idea, and my reading of it is that they have said as much. perhaps they should more clearly state it so for the usual case. my understanding is that you will never fail unless the hardware itself "starts up"? with a broken physical source returning clearly invalid bits. E.g. "In the rare event that the DRNG fails during runtime, it would cease to issue random numbers rather than issue poor quality random numbers." as for stating that it should never "run dry", or fail to not return bits as long as the instruction is working, no matter how frequently it is invoked, see: """ With respect to the RNG taxonomy discussed above, the DRNG follows the cascade construction RNG model, using a processor resident entropy source to repeatedly seed a hardware-implemented CSPRNG. Unlike software approaches, it includes a high-quality entropy source implementation that can be sampled quickly to repeatedly seed the CSPRNG with high-quality entropy. Furthermore, it represents a self-contained hardware module that is isolated from software attacks on its internal state. The result is a solution that achieves RNG objectives with considerable robustness: statistical quality (independence, uniform distribution), highly unpredictable random number sequences, high performance, and protection against attack. .... Protecting online services against RNG attacks [read: high entropy consumption servers] ... Throughput ceiling is insensitive to the number of contending parallel threads """ take with a gran of salt; this is all from their documentation: http://software.intel.com/en-us/articles/intel-digital-random-number-genera… _______________________________________________ cryptography mailing list cryptography(a)randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

[liberationtech] Pakistan Firewall
by nighat＠bytesforall.pk 06 Jul '18

06 Jul '18

You all may like to read something more on Pakistan Firewall. http://futurechallenges.org/local/build-the-great-firewall-follow-the-maste… Regards Nighat Dad Bytes for All, Pakistan @nighatdad _______________________________________________ liberationtech mailing list liberationtech(a)lists.stanford.edu Should you need to change your subscription options, please go to: https://mailman.stanford.edu/mailman/listinfo/liberationtech If you would like to receive a daily digest, click "yes" (once you click above) next to "would you like to receive list mail batched in a daily digest?" You will need the user name and password you receive from the list moderator in monthly reminders. You may ask for a reminder here: https://mailman.stanford.edu/mailman/listinfo/liberationtech Should you need immediate assistance, please contact the list moderator. Please don't forget to follow us on http://twitter.com/#!/Liberationtech ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE

1 0

None
by Peter N. Biddle 06 Jul '18

06 Jul '18

There are a lot of misconceptions about TCPA and Palladium. I am not going to address TCPA per se, but I do want to try to clear up differences and misconceptions around what Pd does. Comments are in-line: ----- Original Message ----- From: "Adam Back" <adam(a)cypherspace.org> To: "Cypherpunks" <cypherpunks(a)minder.net> Cc: "Cryptography" <cryptography(a)wasabisystems.com>; "Adam Back" <adam(a)cypherspace.org> Sent: Sunday, August 04, 2002 10:00 PM Subject: dangers of TCPA/palladium > Like anonymous, I've been reading some of the palladium and TCPA docs. Like anonymous and Adam, I have also been reading lots on Palladium lately. I have also been working on Pd since 1997. > I think some of the current disagreements and not very strongly > technology grounded responses to anonymous are due to the lack of any > concise and informative papers describing TCPA and palladium. I agree, and from my perspective this is a problem. We have a great deal of information we need to get out there. > Not everyone has the energy to reverse engineer a detailed 300-odd > pages of TCPA spec [1] back into high-level design considerations; the > more manageably short business level TCPA FAQs [2], [3] are too > heavily PR spun and biased to extract much useful information from. > > So so far I've read Ross Anderson's initial expose of the problem [4]; > plus Ross's FAQ [5]. (And more, reading list continues below...). We have done technical reviews of Palladium, as shown by Seth Schoen's notes (a), which I think talk directly about many of the things discussed in this thread. I suggest anyone who wants to start to understand Pd read these notes. You don't cite the MS whitepaper. This is not a technical paper but it does set precedent and declare intent. See (b). The suggestions for TCPA responses that William Arbaugh raises seem quite good (c). 1 and 2 are already true for Pd, I believe that 3 is true but I would need to talk with him about what he means here to confirm it, 4 is covered in Eric Norlin's blog (d), and 5 is something we should do. > The relationship between TCPA, and Palladium is: > > - TCPA is the hardware and firmware (Compaq, Intel, IBM, HP, and > Microsoft, plus 135+ other companies) The current TPM (version 1.1) doesn't have the primitives which we need to support Palladium, and the privacy model is different. We are working within TCPA to get the instruction set aligned so that Palladium and TCPA could use future silicon for attestation, sealing, and authentication, but as things stand today the approaches to the two of them are different enough so that TCPA 1.1 can't support Pd. > - Palladium is a proposed OS feature-set based on the TCPA hardware > (Microsoft) Pd is an OS feature set based on new hardware. Pd requires changes to the CPU, chipset and/or memory controller, graphics and USB, as well as new silicon (we call an SCP or SSP), . Microsoft currently has no announced plans to support TCPA directly, and as things stand today there is no SW or HW compatibility between the two. > The main 4 features proposed in the TCPA/palladium scheme are: > > 1. secure bootstrap -- checksums of BIOS, firmware, privileged OS code > are used to ensure the machine knows whether it is running certified > software or not. This is rooted in hardware, so you can't by pass it > by using virtualization, only by hardware hacking (*). This is not how Palladium works. Palladium loads a small piece of code called the TOR after the OS has booted and is running (this could be days later). Pd treats the BIOS, firmware, and privileged Windows OS code as untrusted. Pd doesn't care if the SW is certified or not - that is a question left to users. > 2. software attestation -- the hardware supports attesting to a third > party whether a call comes from a certified software component as > assured by the hardware described in feature 1. In Palladium, SW can actually know that it is running on a given platform and not being lied to by software. In 1, you say that SW virtualization doesn't work, and that is part of the design. (Pd can always be lied to by HW - we move the problem to HW, but we can't make it go away completely). As SW is capable of knowing its own state, it can attest this state to others - users, services, other apps, etc. It can't lie when it uses Pd to say what it is. It's up to third parties (again, the user of the machine, or an app, or service) to decide if it likes the answer and trusts the application. Disclosure of the apps identity is up to the user and no one else. Note that in Pd no one but the user can find out the totality of what SW is running except for the nub (aka TOR, or trusted operating root) and any required trusted services. So a service could say "I will only communicate with this app" and it will know that the app is what it says it is and hasn't been perverted. The service cannot say "I won't communicate with this app if this other app is running" because it has no way of knowing for sure if the other app isn't running. > 3. hardware assisted compartmentalization -- CPU can run privileged > software, and RAM can contain information that you can not examine, > and can not modify. (Optionally the software source can be published, > but that is not necessary, and if it's not you won't be able to > reverse-engineer it as it can be encrypted for the CPU). Confusion. The memory isn't encrypted, nor are the apps nor the TOR when they are on the hard drive. Encrypting the apps wouldn't make them more secure, so they aren't encrypted. The CPU uses HW protections to wall new running programs from the rest of the system and from each other. No one but the app itself, named third parties, and the TOR can see into this apps space. In fact, no one (should the app desire) can even know that the app is running at all except the TOR, and the TOR won't report this information to anyone without the apps permission. You can know this to be true because the TOR will be made available for review and thus you can read the source and decide for yourself if it behaves this way. > 4. sealing -- applications can store data that can only be read by > that application. This works based on more hardware -- the software > state checksums developed in feature 1 are used by hardware to > generate encryption keys. The hardware will refuse to generate the > key unless the same software state is running. Correct enough for this thread; it is actually the TOR that will manage the keys for the apps, as this makes the concept of migration and data roaming far more manageable. (Yes, we have thought about this.) > One good paper to understand the secure bootstrap is an academic paper > "A Secure and Reliable Bootstrap architecture" [6]. > > It's interesting to see that one of the author's of [6] has said that > TCPA as currently formed is a bad thing and is trying to influence TCPA > to make it more open, to exhibit stronger privacy properties read his > comments at [7]. > > There are a lot of potential negative implications of this technology, > it represents a major shift in the balance of power comparable in > magnitude to the clipper chip: > > 1. Potentially cedes control of the platform -- while the palladium > docs talk about being able to boot the hardware with TCPA turned off, > there exists possibility that with minor configuration change the > hardware / firmware ensemble that forms palladium/TCPA could be > configured to allow only certified OSes to boot, period. It's > interesting to note, if I read correctly, that the X-box (based on > Celeron processor and TCPA / TCPA-like features) does employ this > feature. See for example: [8]. Comparing xBox and Pd isn't particularly fruitful - they are different problems and thus very different solutions. (Also note that xBox doesn't use the PID or any other unique HW key.) Palladium mostly doesn't care about the BIOS and considers it to be an untrusted system component. In Pd the BIOS can load any OS it wants, just like today, and in Pd the OS can load any TOR specified by the user. The MS TOR will run any app, as specified by the user. The security model doesn't depend on some apps being prevented from running. I believe that there isn't a single thing you can do with your PC today which is prevented on a Palladium PC. I am open to being challenged on this, so please let me know what you think you won't be able to do on a Pd PC that you can do today. > The documents talk about there being no barrier to certifying TCPA > aware extensions to open-source OSes. However I'm having trouble > figuring out how this would work. Perhaps IBM with it's linux support > would build a TCPA extension for linux. Think about it -- the > extension runs in privileged mode, and presumably won't be certified > unless it passes some audit enforcing TCPA policies. (Such as keeping > the owner of the machine from reading sealed documents, or reading the > contents of DRM policy controlled documents without meeting the > requirements for the DRM policy.) > > 2. DSS over-again -- a big aspect of the DSS reverse-engineering was > to allow DVDs to be played in software on linux. The TCPA platform > seems to have the primary goal of making a framework within which it > is possible to build extensions to implement hardware tamper resistant > DRM. (The DRM implementation would run in a hardware assisted code > compartment as described in feature 3 above). So now where does that > put open source platforms? Will they be able to read such DRM > protected content? It seems likely that in the longer term the DRM > platform will include video cards without access to video memory, > perhaps encryption of the video signal out to the monitor, and of > audio out to the speakers. (There are other existing schemes to do > these things which dovetail into the likely TCPA DRM framework.) I think you mean CSS, not DSS. I don't want people snooping my passwords from the keyboard buffer, nor my account info from the frame buffer, and HW protections in those HW areas prevent that. > With the secure boot strap described in feature 1, the video card and > so on are also part of the boot strap process, so the DRM system would > have ready support from the platform for robustly refusing to play > except on certain types of hardware. Similarly the application > software which plays these DRM policy protected files and talks to the > DRM policy module in the hardware assisted code compartment will > itself be an application which uses the security boot-strapping > features. So it won't be possible to write an application on for > example linux to play these files without an audit and license etc > from various content, DRM and OS cartels. This will lead to exactly > the kind of thing Richard Stallman talked about in his prescient paper > on the coming platform and right to develop competing software control > wars [9]. Palladium doesn't boot strap the OS. Pd loads a secure piece of SW, called the TOR, which runs in a secure space and loads other apps that want security. Anyone can load an app into this environment and get the full protections Pd offers. MS doesn't require that you show them the SW first - you wanna run, you get to run - provided the user wants you to run. If a user doesn't like the looks of your app, then you (the developer) have a problem with that user. > 3. Privacy support is broken -- the "privacy" features while clearly > attempts to defuse a re-run at the pentium serial number debacle, have > not really fixed it's problems. You have to trust the "Trusted Third > Party" privacy CA not to track you and not to collude with other CAs > and software vendors. There are known solutions to this particular > sub-problem, for example Stefan Brands digital credentials [10], which > can be used to build a cryptographically assured privacy preserving > PKI avoiding the linking problems arising from identity based and > attribute certificates. The privacy model in Pd is different from TCPA. I could go on for a long time about it, but the key difference is that the public key is only revealed to named third parties which a user trusts. You are right in thinking that you need to trust them, but you don't have to show anyone your key if you don't trust them, so you (the user) are always in control of this. Pd is not about user authentication - it is about machine and SW authentication. User auth can be better solved on a Pd platform than on a PC today, but it isn't required. Pd doesn't need to know who you are to work. > 4. Strong enforcement for DMCA DRM excesses -- the types of DRM system > which the platform enables stand a fair chance of providing high > levels of enforcement for things which though strictly legally > mandated (copyright licensing restrictions, limited number of plays of > CDs / DVDs other disadvantageous schemes; inflexible and usurious > software licensing), if enforced strictly would have deleterious > effects on society and freedom. Copyright violation is widely > practiced to a greater or less extent by just about all individuals. > It is widely viewed as acceptable behavior. These social realities > and personal freedoms are not taken into account or represented in the > lobbying schemes which lead to the media cartels obtaining legal > support for the erosion of users rights and expansionist power grabs > in DMCA, WIPO etc. I don't know where to begin on this one. It deserves a long, well thought out response, and I don't have the time to do it at the moment. I will follow up on this. Let me state that I think that much of the energy around DRM and HW is misplaced, and that Pd is designed to enable seamless distribution of encrypted information, not to disable distribution of clear text information. > Some of these issues might be not so bad except for the track records, > and obvious monopolistic tendencies and economic pressures on the > entities who will have the root keys to the worlds computers. There > will be no effect choice or competition due to existing near > monopolies, or cartelisation in the hardware, operating system, and > content distribution conglomerates. MS will not have the root keys to the world's computers. The TOR won't have access to the private keys either. No one but the HW does. The TOR isn't "MS" per se - it is a piece of SW written by users but vetted and examined by hopefully thousands of parties and found to do nothing other than manage the local security model upon which Pd depends. You can read it and know it doesn't do anything but effectively manage keys and applications. And if you don't trust it, you won't run it. If you don't trust the TOR, you don't trust Palladium. Trust is the *only* feature we are attempting to achieve, so every decision we make will be made with trust and security in mind. > 5. Strong enforcement for the software renting model -- the types of > software licensing policy enforcement that can be built with the > platform will also start to strongly enable the software and object > rental ideas. Again potentially these models have some merit except > that they will be sabotaged by API lock out, where the root key owners > will be able to charge monopoly rents for access to APIs. I am confused as to how this would work in Pd. Anyone can write apps to the Pd API. Zero restrictions. (API's are full of restrictions - by their nature they limit things to a protocol, and potentially HW, both of which have understood limitations; I am dodging this concept in saying there are no restrictions). > 6. Audits and certification become vastly more prevalent. Having had > some involvement with software certification (FIPS 140-1 / CC) I can > attest that this can be expensive exercises. It is unlikely that the > open source community will be able to get software certified due to > cost (the software is free, there is no business entity to claim > ownership of the certification rights, and so no way to recuperate the > costs). While certification where competition is able to function is > a good thing, providing users with a transparency and needed > assurance, the danger with tying audits to TCPA is that it will be > another barrier to entry for small businesses, and for open source > particularly. This is a problem anyone who wants to compete in the security and trust space will need to overcome. I don't think that it is particularly new or different in a world with Pd. Writing a TOR is going to be really hard and will require processes and methods that are alien to many SW developers. One example (of many) is that we are generating our header files from specs. You don't change the header file, you change the spec and then gen the header. This process is required for the highest degrees of predictability, and those are cornerstones for the highest degree of trust. Unpredictable things are hard to trust. > 7. Untrusted, unauditable software will be able to run without > scrutiny inside the hardware assisted code compartments. Some of the > documentation talks about open sourcing some aspects. While this may > come to pass, but that sounded like the TOR (Trusted Operating Root); > other extension modules also running in unauditable compartments will > not be so published. Everything in the TCB (Trusted Computing Base) for Pd will be made available for review to anyone who wants to review it; this includes software which the MS TOR mandates must be loaded. > 8. Gives away root control of your machine -- providing potentially > universal remote control of users machines to any government agencies > with access to the TCPA certification master keys, or policies > allowing them to demand certifications on hostile code on demand. > Central authorities are likely to be the only, or the default > controllers of the firmware/software upgrade mechanism which comes as > part of the secure bootstrap feature. This doesn't happen in Pd. There is no secure boot strap feature in Pd. The BIOS boots up the PC the same way it does today. Root control is held by the owner of the machine. There is no certification master key in Pd. > 9. Provides a dangerously tempting target for government power-grabs > -- governments will be very interested to be able to abuse the power > provided by the platform, to gain access to its keys to be able to > insert remote backdoors, and/or to try to mandate government policy > enforcement modules once such a platform is built. Think this is > unrealistic? Recall clipper? The TCPA is a generic extensible policy > enforcement architecture which can be configured to robustly enforce > policies against the interests of the machine owner. Clipper, > key-escrow the whole multi-year fight, at some point in the near > future if some of the more egregious TCPA/Palladium framework features > and configuration possibilities becomes widely deployed could be > implemented after the fact, as a TCPA/Palladium policy extentsion > which runs in the hardware assisted code compartment and is > authenticated up to the hardware boot by the secure bootstrapping > process. One of the beauties of Pd is that if there is any SW backdoor, you will know about it. HW robustness will be something for manufacturers to work out. For most systems, I think that extensive HW tamper resistance will be a waste of time, but for some (e.g. highly secure govt systems) it will be a necessity and one that works well in Pd. > So what I've read so far, I think people's gut reactions are right -- > that it's an aggressive and abmitious power grab by the evil empire -- > the 3 cartels / monopolies surrounding PC hardware, Operating systems > and Content Distribution. The operating system near monoply will > doubtless find creative ways to use and expand the increased control > to control application interoperability (with the sealing function), > to control with hardware assistance the access to undocumented APIs > (no more reverse engineering, or using the APIs even if you do / could > reverse engineer). I know that we aren't using undocumented API's and that we will strive for the highest degree of interoperability and user control possible. Pd represents massive de-centralization of trust, not the centralization of it. I think that time is going to have to tell on this one. I know that this isn't true. You think that it is. I doubt that my saying it isn't true is going to change your mind; I know that the technology won't do much of what you are saying it does do, but I also know that some of these things boil down to suspicion around intent, and only time will show if my intent is aligned with my stated goals. > So some of the already applications are immediately objectionable. > The scope for them to become more so with limited recourse or > technical counter-measures possible on the part of the user community > is huge. Probably the worst aspect is the central control -- it > really effectively does give remote root control to your machine to > people you don't want to trust. Also the control _will_ be abused for > monopolistic rent seeking and exclusionary policies to lock-out > competition. Don't forget the fact that microsoft views linux as a > major enemy as revealed by documents uncovered some the anti-trust > discovery process. Pd does not give root control of your machine to someone else. It puts it into your hands, to do with as you so desire, including hacking away at it to your hearts content. > In fact I'd say this is the biggest coming risk to personal freedom > since the days during the onset of the clipper chip / key escrow > looked like they stood some chance of becoming reality. I think that Pd represents an enhancement to personal freedoms and user control over their machines. I hope that over time I will be able to explain Pd sufficiently well so that you have all the facts you need to understand how and why I say this. Peter ++++ (a) Seth Schoens Blog http://vitanuova.loyalty.org/2002-07-05.html (b) MS Paper http://www.microsoft.com/presspass/features/2002/jul02/0724palladiumwp.asp (c) William Arbaugh on TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html (d) Eric Norlin's blog http://www.unchartedshores.com/blogger/archive/2002_07_28_archive3.html#8530 0559 > > Adam > -- > http://www.cypherspace.org/adam/ > > (*) It may be possible to hack the firmware, given access to source > temporarily. > > [1] "Trusted Computing Platform Alliance (TCPA) Main Specification > Version 1.1b", TCPA > > http://www.trustedcomputing.org/docs/main%20v1_1b.pdf > > [2] "TCPA Specification/TPM Q&A", TCPA > > http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf > > [3] "TCPA Frequently Asked Questions Rev 5.0", TCPA > > http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf > > [4] "Security in Open versus Closed Systems (The Dance of Boltzmann, > Coase and Moore)", Ross Anderson, > > (Sections 4 and 5 only, rest is unrelated) > > ftp://ftp.cl.cam.ac.uk/users/rja14/toulouse.pdf > > [5] "TCPA / Palladium Frequently Asked Questions Version 1.0" > > http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html > > [6] "A Secure and Reliable Bootstrap Architecture" > > @inproceedings{Arbaugh:97:secure-bootstrap, > author = "Bill Arbaugh and Dave Farber and Jonathan Smith", > title = "A Secure and Reliable Bootstrap Architecture", > booktitle = "Proceedings of the IEEE Symposium on Security and Privacy", > pages = 65-71, > note = "Also available as \url{http://www.cis.upenn.edu/~waa/aegis.ps}" > } > > [7] "The TCPA; What's wrong; What's right and what to do about", > William Arbaugh, 20 Jul 2002 > > http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html > > [8] "Keeping Secrets in Hardware: the Micrsoft Xbox Case Study", > Andre "bunnie" Huang, 26 May 2002 > > http://web.mit.edu/bunnie/www/proj/anatak/AIM-2002-008.pdf > > [9] "The Right to Read", Richard Stallman, Feb 1997, Communications of > the ACM (Volume 40, Number 2). > > http://www.gnu.org/philosophy/right-to-read.html > > [10] Stefan Brands > > Book "Rethinking Public Key Infrastructures and Digital Certificates - > Building in Privacy", MIT Press, Aug 2000. > > http://www.xs4all.nl/~brands/ > > Number of other technical and semi-technical papers on that page. > > --------------------------------------------------------------------- > The Cryptography Mailing List > Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo(a)wasabisystems.com ----- End forwarded message -----

1 0

[Freedombox-discuss] FabFi mesh network
by Gurdy Leete 06 Jul '18

06 Jul '18

Here's an example of a complete mesh network system that apparently can be built cheaply. Afghans Build Open-Source Internet From Trash http://www.shareable.net/blog/afghans-build-open-source-internet-from-trash… http://fabfi.fabfolk.com/ http://fabfi.fablab.af/blog/ Instructions for creating and configuring hardware and software, including servers, nodes and reflectors, are here: http://code.google.com/p/fabfi/wiki/HowToMake A New York Times article this weekend on subversive community communication networks <http://www.nytimes.com/2011/06/12/world/12internet.html> includes a photo of the FabFi Afghanistan mesh network. _______________________________________________ Freedombox-discuss mailing list Freedombox-discuss(a)lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/freedombox-discuss ----- 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