Overview

Our system consists of publishers who post Publius content to the web, servers who host random-looking content, and retrievers who browse Publius content on the web. At present the system supports any static content such as HTML pages, images, and other files such as postscript, pdf, etc. Javascript also works. However, there is no support for interactive scripting such as CGI. Also, Java applets on Publius pages are limited in what they can do. We assume that there is a static, system-wide list of available servers. Publius content is encrypted by the publisher and spread over some of the web servers. In our current system, the set of servers is static. The publisher takes the key, K that is used to encrypt the file to be published and splits it into n shares, such that any k of them can reproduce the original K, but k-1 give no hints as to the key [22]. Each server receives the encrypted Publius content and one of the shares. At this point, the server has no idea what it is hosting - it simply stores some random looking data. To browse content, a retriever must get the encrypted Publius content from some server and k of the shares. As described below, a mechanism is in place to detect if the content has been tampered with. The publishing process produces a special URL that is used to recover the data and the shares. The published content is cryptographically tied to the URL. Any modification to the stored Publius content or the URL results in a failed tamper check. If all tamper checks fail the Publius content cannot be read. In addition to the publishing mechanism, we provide a way for publishers (and nobody else) to update or delete their Publius content. In the next several sections, we describe the Publius functions in some detail. We use a simple example of a publisher with one HTML file. Publishing more complicated content, such as web pages that have links to each other, is covered in Section 4.

  

Figure 1: Publish Algorithm