Publius (publishing system)

Design goals

The nine design goals of the Publius development team are:

Overview

The Publius web system consists of the following agents:

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.

Operations

The Publius protocol allows the following operations:

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

1. Random symmetric key K is generated.
2. The original content M is encrypted under Symmetric-key algorithm with the key K. Resulting with the encryption E(M,K).
3. 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.
4. For each of the n shares, the following computation takes place: n a m e i   = w r a p ( H ( M ∗ s h a r e i ) ) where M ∗ s h a r e i is the concatenation result of the original contents M with the key share s h a r e 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.
5. The hosting servers are chosen out of the servers list; the chosen locations in the servers list are determined by l o c a t i o n i = ( n a m e i   m o d   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.
6. In each server which appears in the servers list at l o c a t i o n i a directory named n a m e i is created containing the encrypted contents E ( M , K ) , the chosen server's share of key K (namely, s h a r e 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).
7. A unique Publius URL is constructed by concatenation of the d different n a m e 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 l o c a t i o n i at the servers list holds the following files under a directory named n a m e i :

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:

1. The URL is parsed back into 8 bytes units (which are the n a m e i units which were concatenated during the publish process).
2. For each n a m e i unit parsed out of the Publius URL, the hosting server is located from the servers list by computing l o c a t i o n i = ( n a m e i   m o d   m ) + 1 which indicates on the server's location in the list.
3. 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.
4. 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 n a m e i .
5. 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 n a m e i directory.
6. The original message is decrypted from E(M,K) using the reconstructed key K.
7. The retriever then verifies that the contents M wasn't modified nor did the key share s h a r e i by recomputing w r a p ( H ( M ∗ s h a r e i ) ) and comparing it with the corresponding n a m e i 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 ( S D N ∗ P A S S W D ) (namely, the MD5 hash result for the concatenation of the server domain name with the publisher's password) is sent along with the corresponding n a m e i string and compared with the one already stored in the password file under the directory n a m e 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 n a m e 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 n a m e 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:

h t t p : / / ! a n o n ! /   o p t i o n s   n a m e 1   n a m e 2   . . .   n a m e n

Where n a m e 1 n a m e 2 . . . n a m e 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:

Security analysis