Summary Tangler: a Censorship-Resistant Publishing System Based On Document Entanglements Marc Waldman and David Mazières 8th ACM Conference on Computer and Communcation Security (CCS-8),(November, 2001). This paper describes a system for publishing documents. In particular, this system is meant to be censorship-resistant in that it is very difficult to remove/change/censor published content. The main idea here is to create dependencies between various documents within the system, so as to create an "entanglement." Files are so dependent on each other, that users in the system are forced to keep multiple replicas of other people's files, thus making replication a natural consequence in the system. Some properties of a censorship-resistant publishing system are: 1. Documents should not be associated with any particular server (otherwise the administrator can be forced to remove the files) 2. Source should be anonymous (author cannot be held accountable, or forced to change the document) 3. Spread over various countries (weakens the stronghold of governments) 4. Tamper resistant, through hashes Tangler Organizes documents in collections. These collections represent content published by the owner of a private key and indexed/accessed by the public key. In order to publish a document within a collection, the file is broken up into blocks and "tangled" with blocks randomly fetched from the system. The resultant system blocks are then published to the system, which are indexed (magically) by their hash values. For obvious reasons, each file has an associated inode that keeps track of which blocks are required to reconstruct the file blocks. Tangler Network Misbehaving servers can be detected and temporarily removed. An interesting scheme of using "witnesses" for failed requests is used to identify misbehaving servers. They suggest an interesting hashing function whereby around 1/14 of the mappings change everyday, making sure that files migrate around, and are not bound to any particular server. They have a storage credit system whereby systems are given credits for storage on other systems. These can be redeemed in return for storage certificates. Conclusion The authors have designed a system to publish documents that are hard to delete because they are tangled with other files, and inherently replicated in the process. Furthermore, deleting blocks of one file would make other files unreadable, thus providing no incentive to an administrator to delete such documents. Pros There is a fundamental human right to freedom of speech and expression. Oppressive governments, corporations and individuals attempt to destroy that right. They may attempt to coerce system owners and authors through litigation, or physical threats. They may launch denial of service attacks, or attempt to subvert the publication process. Tangler can greatly reduce the ability to perform censorship via these methods. While such a system could be used for unlawful purposes, limiting such a system would not be necessary or sufficient to guarantee security of protected information and would unduly limit protections for potentially unpopular speech. The integrity of the system is insured by requiring useful work to be performed by serves and by cryptographic techniques. Anonymity protects the authors of documents from direct coercion. Authors are motivated to support the publication of materials by use entanglement. This leads to increased replication. The features of the system such as the use of version information to support updating and pseudonymous collections benefit the user community. While the system is not scalable it is efficient and will serve the foreseeable practical need. Compared with other systems Tangler provides better replication and migration of data to insure availability in the face of the legal and denial of service threats considered. Cons How does one incrementally publish? It looks from the publishing algorithm (4.4) that single mapping between your public key and your entangled inode blocks. If this is done with versioning, it's not clear how this all works. Newer soft links are not supposed to be able to point older versions stored in the entanglement. How does one get the collection root? Where is this information stored? How is this information retrieved? Must pay to be able to publish (in terms of providing storage). If you cannot pay to publish, a publisher may offer "publishing services" at a reasonable rate with "minor" editorial control. The older your content in the system the more of a foundation of other documents it will likely be. So where do we lay the foundation--or how is the set of server blocks bootstrapped? Blocks must be refreshed every two weeks. One has to constantly feed your blocks into the system. Protection against "automatic spamming programs" would seriously hinder any sort of automatic attempts at storing "your blocks" on other servers. Finding server blocks requires hashing all server keys to find successors on the circle (figure 3). Expulsion is never really quantified. System requires anonymous electronic payment, which does not exist yet Content needs to be refreshed every two weeks, so it would be possible to just kidnap publisher and force the stuff to retire. Finding documents becomes difficult when the names are hard to remember Depending on how keys are obtained, could trace key to publisher. If publisher makes up their own keys, then there will be a need to check for duplicate keys In part, relies on the unwillingness to destroy other documents, but sometimes, the attacker may not care what they destroy.