Publius Publishing System

Publius is (was?) a web protocol developed by Waldman, Rubin & Cranor for allowing individuals the ability to publish information on the web anonymously and with a high guarantee that their publications will not be censored or modified by a third party.

The nine design goals of the Publius development team are:

Censorship resistance - decreasing the chance that a third party will manage to modify or delete the published materials.
Tamper evident - unauthorized changes are traceable.
Source Anonymous - there is no way to tell who published the material once it is available on the web.
Updatable - publishers are allowed to modify or delete their material.
Deniable - third parties participating in publishing the materials lacks the responsibility for the hosted content.
Fault tolerant - system should function even when some involved third parties are faulty or malicious.
Persistent - there is no expiration date for published materials.
Extensible - support for future protocol extensions or growth in the number of publishers.
Freely available - all software tools required for the system should be out of charge.

Overview

The Publius web system consists of the following agents:

Publishers - participants who publish their contents on the web.
Servers - which host the publishers' contents on the web (considered as part of the third parties).
Retrievers - participants who browse the web contents published by the publishers.

The Publius system relies on a static list of m web servers. When a publisher wishes to add a contents M to the web, it first encrypts M using some random symmetric key K. Then K is split into n shares (parts) where at least k<n shares are required for the reconstruction of K (see also Secret sharing). A subset of the m servers receives another share of K and the encryption result of M using the key K, E(M,K).
When a retriever wishes to obtain the original contents M, it follows a generated URL which corresponds to the contents M combined with the portion of K as it appears on a subset of servers from the list. Gathering k different shares and a copy of E(M,K) allows the retriever to reconstruct the key K out of the shares and decrypt E(M,K) back into M. Modification or removal of the server hosted contents can be issued only by the original publishers using a combination of password and the hosting server domain name.

At present, Publius supports the hosting of HTML pages, images and other file formats such as PDFs and PostScripts.

Detailed View

This section covers the Publius protocol in greater details.

Operations

The Publius protocol allows the following operations:

Publish - in which a publisher spreads its contents across the Publius web servers.
Retrieve - in which a retriever follows a specific URL to gather desired contents.
Update - in which a publisher replaces its server hosted contents file by another.
Delete - in which a publisher removes its server hosted file.

When a publisher wishes to add a web contents in the Publius web, its Publius client software (Publius Client Proxy) executes the following steps:

Random symmetric key K is generated.
The original content M is encrypted under Symmetric-key algorithm with the key K. Resulting with the encryption E(M,K).
K is split into n shares using Shamir's Secret Sharing method in such that at least k<n shares are required for the reconstruction of K under the method of interpolation.
For each of the n shares, the following computation takes place: $name_i\ = wrap(H(M * share_i))$ where $M*share_i$ is the concatenation result of the original contents M with the key share $share_i$ ; H is the MD5 cryptographic hash function and wrap is the bitwise xor result of the two halves of the string which returned by H.
The hosting servers are chosen out of the servers list; the chosen locations in the servers list are determined by $location_i = (name_i \ mod \ m) + 1$ in order to obtain n values in the range [1,m]. If less than k unique locations were found, this step is repeated till $d>=k$ unique locations are found.
In each server which appears in the servers list at $location_i$ a directory named $name_i$ is created containing the encrypted contents $E(M,K)$ , the chosen server's share of key K (namely, $share_i$ ) and additional information(a password file containing the MD5 hash value of the chosen server domain name concatenated with a user chosen password used for authentication when a publisher wishes to update or remove its contents from the server).
A unique Publius URL is constructed by concatenation of the d different $name_i$ identifiers of the servers containing the encrypted contents M and a key share of K.

Diagram describing the selection of servers out of the servers list to hold encrypted contents under hashed directory names.

After the publish operation is done, each chosen server at location $location_i$ at the servers list holds the following files under a directory named $name_i$ :

file - which contains encrypted E(M,K) contents of the original contents M.
share - which holds the share of the chosen server of the encryption key K (namely, $share_i$ ).
password - which holds the MD5 hash value for the concatenation of the server domain name with a user chosen password. This is used for authentication for delete or update operations initiated by the publisher for the contents hosted by the chosen server.

When a retriever wishes to browse for a web contents in the Publius web, its Publius client software (Publius Client Proxy)executes the following steps:

The URL is parsed back into 8 bytes units (which are the $name_i$ units which were concatenated during the publish process).
For each $name_i$ unit parsed out of the Publius URL, the hosting server is located from the servers list by computing $location_i = (name_i \ mod \ m) + 1$ which indicates on the server's location in the list.
k servers are chosen arbitrarily out of the located servers in order to reconstruct the key K using an interpolation over the retrieved k shares, one from each chosen server.
Among those k chosen servers, one is chosen for retrieving the encrypted contents E(M,K). This is issued using an HTTP GET request to the server for a file named file stored in the server directory named $name_i$ .
The k shares of the key K are fetched in a similar way, known to be located in a server file named share under the $name_i$ directory.
The original message is decrypted from E(M,K) using the reconstructed key K.
The retriever then verifies that the contents M wasn't modified nor did the key share by recomputing and comparing it with the corresponding chunk which was parsed from the Publius URL.
1. If a mismatch was found, another set of k servers can be tried, or maybe the contents should have been downloaded from another server.
2. If verified successfully, the original contents M can be viewed by the web browser.

The delete operation is implemented by invoking a CGI script running over the servers. To each server the hash result of $H(SDN*PASSWD)$ (namely, the MD5 hash result for the concatenation of the server domain name with the publisher's password) is sent along with the corresponding $name_i$ string and compared with the one already stored in the password file under the directory $name_i$ ; if there is a match, the file file is removed from that directory.

The update operation similarly uses the hashed concatenation of the server domain name with publisher's password in order to authenticate the original ownership of the hosted contents. Under this operation, the update itself is done by adding additional update file under the $name_i$ which contains the new Publius URL matching for the updated contents (recall that the Publius URL is tied with the published contents and the share of the encryption key and is verified against the contents when retrieved). In fact, the update operation is equivalent to the publish operation with the addition of adding the update file to the old $name_i$ directory for redirecting future retrieve request to the new URL. When a retrieve operation will be issued for the old URL, the Publius proxy client will be redirected to fetch the new URL, the same will be done with the rest of the k-1 chosen servers; if the k resulting URLs do not match, then another set of k servers will be chosen for retrieval.

Publius URLs

Encrypted web contents in the Publius protocol are traceable by their Publius URLs. Those have the following format:

$http://!anon!/ \ options \ name_1 \ name_2 \ ... \ name_n$

Where $name_1name_2...name_n$ is the concatenation of the hash results of the original contents combined with some key share, as were described for the publish operation in the previous section. The options section of the URL is 16 bits represented by a two characters ASCII string, containing:

version number - which allows the extension of the protocol and backwards compatibility when interacting between different versions.
number of shares required for key reconstruction.
update flag - which its purpose will be mentioned in the next section.

Security Analysis

In order for a Publius contents (or its update) to become inaccessible, it is required that all of the n copies of the encrypted contents will be deleted or corrupted so they will fail the verification against their URL. Another possibility is by losing more than n-k of the encryption key K shares; leaving us with less than k shares which are insufficient for the reconstruction of K. Choosing high values for n and low values for k guarantees low chance of inaccessible contents to occur.
Tampering in the form of inserting false updates by third parties can become unlikely as the value for k increases. Larger value for k means that more shares will participate in the verification of the retrieved contetnts and by doing so, increasing the chance that such modification will be noticed.
The update flag field in the Publius URL is useful for prevention from redirecting to a false updates; even if a false update was added by a third party, it will be ignored as long as the update flag in the URL is set to zero.

External links

See also: Gibbs, W. Wayt: "Speech Without Accountability", Scientific American 283:4 (Oct 2000)

This article is issued from Wikipedia - version of the Saturday, March 29, 2014. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.