[Mnet-devel] PET 2004: 5 minute rump session talk

Zooko zooko at zooko.com
Wed May 26 16:49:36 BST 2004


These are the notes I wrote for what I intend to say at the rump 
session on Thursday.  I've practiced it a couple of times, and it 
clocks in at just under 5 minutes.

--Z

I. Intro
Mnet is a decentralized filesystem, comparable to Freenet, OceanStore, 
and GNUnet.  The goal of Mnet is to be useful to lots of real-world 
users as a self-organizing, attack-resistant virtual space in which to 
store files.

In the next 4 minutes I will describe the basic architecture of the 
Mnet filesystem.  In the remaining minute, I will point out a basic 
assumption that we relied upon when designing Mnet that I would like to 
see challenged in order to open up the way for future systems of this 
kind.

II. How it works
A. In Mnet, every node knows about every other node.  This is obviously 
non-scalable, as it implies a cost on each node which is proportional 
to the size of the whole network.  However for cases where the network 
is not too large, this design seems to offer excellent performance, 
flexibility, and robustness.
B. Every node generates an RSA keypair.  All communications are 
encrypted and authenticated using these keys (using a hybrid 
cryptosystem for efficiency).  Each node has a "nodeId" which is the 
SHA1 hash of its public key.
C. To store a file on Mnet, you perform four steps:
  1. Erasure code, generating 3 parity blocks for every data block of 
the file.
  2. Encrypt the blocks (both original data blocks and parity blocks) 
using a symmetric encryption key of your choice.
  3. Let the SHA1 hash of the encrypted block be the "blockId".  Now 
send each encrypted block to the node whose nodeId is closest to the 
blockId in some metric.
  4. Now you have a list of blockIds.  Call this list the "inode".  
Treat the inode exactly like you treat data blocks: encrypt it and 
store it on the node whose nodeId most closely matches the inode's 
blockId.
Now the blockId of the inode, plus the symmetric encryption key, is 
necessary and sufficient for anyone to retrieve the blocks and 
reconstruct the original contents of the file.

III. Assumption
A basic assumption that we made in the design of Mnet is that there 
will be a single large network comprising all of the users, who are 
"cooperating strangers".  I would like to learn about the consequences 
of alternative assumptions.  Two alternatives that come to mind are 
"Friend-of-a-Friend" networks like a decentralized version of 
Friendster, and "clubs" where there are many small networks, and all 
participants in a single network are socially related as being members 
of the same group.  George Danezis has recently published a paper which 
explores these very ideas.




More information about the Mnet-devel mailing list