Censorship-Resistant Publishing Systems Marc Waldman Computer Science Department

Censorship-Resistant Publishing Systems Marc Waldman Computer Science Department New York University

What is a Censorship-Resistant Publishing System? A system that maintains document availability in the presence of adversaries who wish to suppress the document.

Why Censorship-Resistant Publishing? n Political Dissent n “Whistleblowing” n Human Rights Reports

Possible Solutions n Collection of WWW servers - CGI scripts to accept files - each file replicated on other participating servers n Usenet - Send file to Usenet server - Automatically replicated via NNTP

Small group of WWW servers n Censorship-resistant properties - replication of content - multiple administrators n Problems - Small static set of servers - Flooding - Overwriting or deleting - Name Squatting

Usenet n Censorship-resistant properties - globally distributed (resists admin threats) - huge capacity (resists storage flooding) n Problems - published document (article) short lived - propagation time unpredictable - no tamper check mechanism - cancel/supercede requests - easily filled with meaningless articles

Document Availability Threats n Legal and illegal threats against server admin n Adversarial content modification n Document Flooding n Legal and illegal threats against publisher n Name Squatting n Malicious hosting servers

“Eternity Service” Proposal n Worldwide collection of servers that store documents (prevents legal threats) n Publisher pays (anonymous e-cash) for document to be published on random subset of servers (prevents document flooding) n Once published, document can’t be deleted (prevents illegal threats against publisher) n Request and receive documents via anonymous communication channel (protects readers)

“Eternity Service” Design Challenges n Servers - Adding, removing, adversarial servers n Document Naming - name squatting, updating, searching n Replica Placement - efficient retrieval

“Eternity Service” Design Challenges n Content Storage - File or block based storge, encryption n Tamper Protection - Detect malicious & accidental tampering n Untraceable Communication Channel - “Real-time” or e-mail based

Eternity Service Inspired Censorship-Resistant Systems n n Design goals similar to Eternity Service Scaled down design, some implementations available - Janus - Rewebber - Usenet Eternity - Freenet - Free. Haven - Publius - Tangler

Janus Provides URL rewriting service to hide true location of WWW page n Based on public key cryptography n Ek (U)=Encrypt URL U with public key k U=http: //www. cs. nyu. edu/ Janus URL hides true location of U http: //www. rewebber. de/surf-encrypted/Ek(U) n n Janus acts as HTTP proxy, retrieving and rewriting pages.

Janus In Action User 1 http: //www. rewebber. de/surf-encrypted/Ek(U) 4 Janus index. html with URLs encrypted 2 http: //www. cs. nyu. edu 3 index. html Internet

Janus For Censorship-Resistant Publishing n Must trust Janus not to divulge true URL n Not fault-tolerant - Janus URL encodes single server - Access available only through Janus n Janus controls all returned content - Content could be modified or censored

Taz and Rewebber n Collection of volunteer servers - Each has public/private key pair - Public keys well known to all users - Each runs a special HTTP proxy server n URL to hide is encrypted using layered technique - Similar to onion-routing - Results in long URLs n TAZ servers translate names to URLs

Rewebber Layered Encryption Publisher uses public keys of servers to encrypt URL “nyu. edu” Want URL to be hidden behind 5 other servers. Encrypt in reverse path order (use public key of server 5 first) Server 1 Server 2 Server 3 Server 4 Server 5 http: //Very. Long. URL Medium. URL Small. URL nyu. edu

Taz and Rewebber In Action User TAZ Server 1. Apple_Pie_Recipe. taz 2. http: //Very. Long. URL 3. http: //Very. Long. URL 4 Long. URL 5 Medium. URL 6 Small. URL 7. get recipe. html Apple. Pie. com

Rewebber For Censorship-Resistant Publishing n Do not need to trust single entity - Single coopering server hides true URL n Allows anonymous retrieval - No limit on URL size - Padding can be applied after each decryption n Not fault tolerant - Single faulty or malicious server can prevent document from being retrieved n No tamper protection mechanism - A server can modify content on return trip

Publius n Collection of volunteer servers - Each server donates disk space - Runs script to interpret Publius commands n Publication process encrypts document - encrypted document stored on subset of servers - part of encryption key stored with document n Publication process results in a Publius URL - Tells location of encrypted documents - Provides tamper check mechanism n Provides secure update and support for mutually hyperlinked content

Cryptographic Hash A function that takes an arbitrary sized input and maps it to a fixed sized output value such that 1) It is computationally infeasible to find a specific input that matches a pre-specified output 2) It is computationally infeasible to find any two distinct inputs that map to the same output MD 5 cryptographic hash output = 128 bits SHA-1 cryptographic hash output = 160 bits

Publius Servers Publius Server Table www. redcross. org whitehouse. gov library. fr www. nyu. edu publius. uk

Publish Operation D = Document To Publish K Share 1 K=Encryption Key Shamir Secret Sharing Share 2 Share 3 Share 4 MD 5 ( D. Sharei ) Mod 5 = Index Into Server Table Index 3 = www. nyu. edu Store D encrypted under K, and Sharei on www. nyu. edu

Publius URL Cryptographic hash value determines location of document. MD 5 ( D. Sharei ) Mod 5 = Index Into Server Table To Form Publius URL – Perform hash on each Share and concatenate resulting MD 5 values. http: //!publius!/1 e 6 adsg 673 h 0=hgj 7889340=yareyoureading this=12 asbnm 8945 The URL is cryptographically tied to document. Provides a tamper check mechanism.

Publius Retrieve Operation Break apart URL to discover document locations n Retrieve encrypted document and share from k locations n Reassemble Key K from shares n Decrypt retrieved document n Check for tampering n View in WWW browser n All work done by a client-side HTTP proxy n

Publius For Censorship-Resistant Publishing n Fault tolerant – don’t need all shares or documents to retrieve document n Tamper resistant – All documents retrieved from servers are checked for tampering n Encryption protects hides content from someone who doesn’t know URL (including server admin) n Scalability problems – Everyone needs list of servers n Flooding can be a problem. Publius file size limit is 100 K.

The Tangler Censorship-Resistant Publishing System n Designed to be a practical and implementable censorship-resistant publishing system. n Addresses some deficiencies of previous work n Contributions include – - A unique publication mechanism called entanglement - The design of a self-policing storage network that ejects faulty nodes

Tangler Design n Small group (<100) of volunteer servers n Each server has public/private key pair n Each server donates disk space to system (publishing limit) n Agreement on volunteer servers, public keys and donated disk space n Published documents are divided into equal sized blocks, and combined with blocks of previously published documents (entanglement) n Entangled blocks are stored on servers n Each server verifies other servers compliance with Tangler protocols

Tangler Goals n Anonymity – Users can publish and read documents anonymously n Document availability through replication n Integrity guarantees on data (tamper & update) n No server is storing objectionable documents - Decoupling between document and blocks - Blocks not permanently tied to specific servers - Server cannot chose which blocks to store or serve n Misbehaving servers should be ejected from system

Publish Operation n Document broken into data blocks n Data blocks transformed into server blocks n Server blocks combined with those of previously published server blocks (entanglement) n Entangled server blocks are stored on servers Data Blocks Server Blocks Previously Published Server Blocks + New Server Blocks

Document Retrieval Operation n Retrieve entangled server blocks from servers n Entanglement is fault tolerant – don’t need all entangled blocks to re-form data blocks n Dis. Entangle Operation re-forms original data blocks Entangled Server Blocks Data Blocks

Block Entanglement Algorithm n Utilizes Shamir’s Secret Sharing Algorithm - Given a secret S can form n shares - Any k of them can re-form S - Less than k shares provide no information about S n Entanglement is a secret sharing scheme with n=4 and k=3 n Two shares are previously published server blocks n Two additional shares are created

Benefits Of Entanglement n Dissociates blocks served from documents published - Single block belongs to multiple documents - Servers just hosting blocks n Incentive - Cache server blocks of entangled documents - Monitor availability of other server blocks - Re-inject blocks that have been deleted

Tangler Servers (Tangle-Net) n All servers fall into one of two categories – non-faulty = follow Tangler protocols faulty = servers that exhibit Byzantine failures n All non-faulty servers are synchronized to within 10 minutes of correct time. n Time is divided into rounds (24 hour period) - Round 0 = Jan 1, 2002 (12: 00 AM) n Fourteen consecutive rounds form an epoch

Tangler Round n Round Activity (concurrent actions) - Request storage tokens from other servers - Grant storage tokens to other servers - Send and receive blocks - Monitor protocol compliance of other servers - Process join requests - Entangle new collections and retrieve old collections n End of round - Commit to blocks received from servers (Merkle Tree) - Generate public/private key pair for the round - Broadcast next round commitment and public key

Storage Tokens n Two step protocol to store blocks n First Step - Acquire storage tokens - Every server entitled to number of storage tokens from every other server - Tokens acquired non-anonymously, requests are signed by requestor n Second Step – Redeem Token - Send block & token anonymously to storing server - Anonymous communication supported by Mix-Net

Storage Token Request n Server A wants to store block 92180 on Server B n Server A creates a blinded request for a token n The blinded request is sent to server B n Server B signs the request and returns it to A n Server A unblinds request obtaining the token Server A Server B XXXXX 92180 Server A XXXXX 92180 Unblind Token Server B Server_A_Tokens--

Redeeming A Token n Server A sends token & block through Mix-Net to B Server B checks token signature, stores block, and returns signed receipt over Mix-Net Server B commits to hash tree of all blocks Server A Mix-Net Server B 92180 storage receipt block 92180 Server B

Membership Changes n At end of epoch all non-faulty servers perform Byzantine Consensus algorithm n Each server can vote out any other members n New servers can join at any time but must serve as a storage-only server for a probationary period of two complete epochs n A probationary server is admissible if it was not ejectable for at least two consecutive epochs. n Majority vote wins

Threats n Majority of servers are adversarial - Adversarial servers join - Force non-faulty servers off n Publishing server discovery - Force suspected server off network - Should be able to republish on another server but may not have same credit limit n Probabilistic failure (difficult to remove)

Summary n There is a need for censorship-resistant publishing tools. n Several systems have been proposed and some have been implemented. n Each system has strength and weaknesses. System design is greatly influenced by your adversary model.

Publius and Tangler URLs n Publius www. cs. nyu. edu/~waldman/publius. html n Tangler www. scs. nyu. edu/tangler