Technical Notes
Technical Abbreviations Database
TN0001: Draft Specification - Implementation of Gelernter Cyberbodies
Implementation of Gelernter Cyberbodies
The purpose of this document is to provide a first quick and dirty specification and implementation of cyberbodies with their distributed storage. The code is proof-of-concept only, and the whole purpose of this specification is to clarify goals.
(c) July 17, 2001 by Carsten Kuckuk, Ludwigsburg, Germany, E-Mail: , permission is granted to modify and distribute this document in its entirety in the spirit of the GPL license .
There is a need for a combined single sign-on system that allows Internet users to approach any computer that is available, log on on this computer and have a familiar environment with all their personal information and services at their disposal. In the context of this document, "having information and services available" can be interpreted as "knowing the Internet address of a computer that contains it, and knowing how to access this computer and which username/password combination to use". The collection of this critical information is called a cyberbody. Login on to a computer is interpreted as retrieving the cyberbody from servers on the Internet. Making use of the cyberbody is interepreted as running a Java application that displays the list of all services contained in the cyberbody to the enduser, have him select a service, and start a helper application that accesses the service. In order to store a cyberbody, the cyberbody is transformed into two binary strings that look like random numbers. These two strings are stored on different computers on the Internet using a simple username / password protection scheme. In order to access a cyberbody from anywhere in the world, the end-user has to memorize the locations and username / password combination of these two computers where the cyberbody is stored on.
The remainder of this document consists of the following parts:
Part 1: Specification of a cyberbody explains the exact composition of a cyberbody.
Part 2: Storage form of a cyberbody describes how the cleartext information of a cyberbody is transformed into two strings that expose the statistical properties of random numbers. This form is the storage form of a cyberbody.
Part 3: Access and Update Protocol for stored cyberbodies describes how the two parts of a cyberbody can be retrieved from the Internet, and how modified versions can be stored. At the heart of it there is a comit/rollback mechanism combined with username / password authentification.
Part 4: A sample client using cyberbodies implemented in Java is a simple Java application that retrieves cyberbodies, allows the client to access the services stored in it, allows the client to modify cyberbodies and store them.
Part 5: A sample server storing cyberbodies implemented in PHP gives the necessary scripts for implementing a cyberbody storage on a LAMP server.
Part 6: Future improvements describes what has to be done in the future to make this system more practical.
Cyberbody: Collection of personal authentication data that is needed to access web services
Web Service: Simple things like e-mail, file storage/ftp, bulletin boards, calender, link collection, address books
A cyberbody is a list of lines each describing one service. A service consists of a service description (protocol part of the URL), a web address, a username, a password and a comment that is displayed to the end-user.
Cyberbody := "" {WebServiceAccessInfo} ""
WebServiceAccessInfo := URL " " Username " " Password " " Comment

http://www.kuckuk.com/ - - My favourite web site
pop3://www.kuckuk.com/ ck nuknuk My POP3 account
ram://www.wdr3.de/ - - My favourinte radio station
ftp://ftp.kuckuk.com/ ck nuknuk My file storage
app://www.kuckuk.com/apps/JWord.jar ck nuknuk My favourite Word editor

In order to store a cyberbody, the cleartext form of the cyberbody is transformed into a storage form that consists of two strings of bytes of the exact same length. Due to the way these strings are generated, they both look like strings of random numbers.
Let c_i, i=0..n be the binary representation of the cyberbody.
Let r_i, i=0..n be a random bytes.
Let s_i := c_i XOR r_i, i=0..n
The storage form of the cyberbody consists of the byte sequence r_i and the byte sequence s_i.
Given the storage form of a cyberbody as two byte sequences r_i and s_i, the cleartext form of the cyberbody can be calculated as c_i:=r_i XOR s_i.
The desired property of this storage form is, that both sequences expose the statistical properties of random numbers. Both sequences are needed to restore the cleartext form. So if each sequence is stored on its own computer, and the computers are sufficiently far away from each other, and the owners of the computers don't know about each other, then the stored data can not be retrieved at all by any one of the two server owners. Trusting the operators of the servers that store the cyberbodies is not necessary at all.
In order to access or modify a stored cyberbody sequence, the requester must present a valid username and password to the computer. In order to allow for recovery from incomplete modifications or a single lost update due to a server crash, two versions of the storage form of a cyberbody are stored on each server together with a version number. The accessing client gets both sequences and uses the newest version that both servers have stored. Let C be the client computer and S be the server computer that has stored the cyberbodies. I don't know the details by heart, but the parameters are passed as if this were an HTML form submission with a GET action.
Retrieving a Cyberbody:
c->s: GET HTTP://www.server.com/dotnet/cyberbody/get.php?u=username&p=password
s->c: OKContent-Length: xxx33:lenbytes:XXXXXXXXX34:lenbytes:YYYYYYYYY
(Like a form with parameters "u" and "p") If the user is known and the password is correct, the server returns the current and the next-to-current cyberbody. It is the Java client's task to determine which version to use. In the case of an authentication error only an error message is returned.
Storing a modified Cyberbody: c->s: GET HTTP://www.server.com/dotnet/czberbody/put.php?u=username&p=password&v=35&body=XXXXXXX
s->c: OK
(Like a form with parameters "u", "p", "v" and "body") If the user is known and the password is correct, and the version number is higher or equal to the highest version number stored in the database, the new version is stored in the database, and the oldest version is deleted from the database.
- Ask user for server1, username 1, password 1
- Ask user for server2, username 2, password 2
- Contact servers, retrieve storage sequences with version numbers
- Select a complete pair of sequences with the highest possble version number. Memorize version number.
- Calculate the cleartext of the cybebody from the storage form.
- Display Services from Cyberbody
- Display possible commands: (1) Use Service n, (2) Add a service, (3) Delete a service, (4) Update profile
- Wait for a command
Command 1: Use Service n: Determine n, determine cyberbody[n], invoke service
Command 2: cyberbody[max+1]=input line
Command 3: delete entry cyberbody[n]
Command 4: version++; create sequences r and s;
server1->Put(user,pwd,version,r); server2->Put(user,pwd,version,s);
End Loop


- Use digest authentication for the access protocol
- Use PUT for the access protocol
- Define gobs of services for the URL

(Added) November 07, 2002
A new article "Forget the Files and the Folders: Let Your Screen Reflect Life" by David Gelernter appeared in the New York Times on November 07, 2002.

Document History
First Version: July 17, 2001 sent as an e-mail to the mailing list auth@dotgnu.org
Second Version: July 18, 2001, put on my web site as http://www.kuckuk.com/public/tn/tn0001.html
Third Version: November 07, 2002, added the Links section

If you have any questions, please send e-mail to Carsten Kuckuk at .