back to main page

How Blocks Works (this probably needs more work)

Connection Management - How Blocks Builds A Network

  1. When the public Primary Server starts up it sits and listens for connections.
  2. New servers are explicitly told the location of the Primary Server and connect.
  3. Both sides then create a session key based on a 512bit Diffie-Hellman Key Exchange.
  4. The connecting server (if it has a listening port) then advertises itself to the Primary Server.
  5. If the Primary Server has more than 10 connections it tells the connecting server to disconnect once it has enough connections of its own.
  6. The Primary Server forwards the advert to any other connected servers (the advert includes the IP address and port of the new server).
  7. Each server which receives the advert may choose to conect to the server (choice determined by a PRNG and how many connections it already has), or to forward the advert to other connected servers.
  8. If the new server was told by the Primary Server to disconnect, it does so once it has more than 4 connections.
  9. Servers with less than 6 connections may readvertise to adjacent servers periodically (every hour or so).
  10. Servers with no connections may elect to reconnect to the Primary Server.
And thats how the Blocks 'network' gets built.

File Advertisements

  1. When a file is uploaded a hash of the encrypted contents of the file is created.
  2. This hash, along with the filename, and filesize, is sent to all adjacent servers.
  3. When each server receives the advert (and decides that it is a new advert and not one which has been routed round in circles) it attaches a character A-P noting which connection the advert came from.
  4. The advert is then added to the advert cache unless an advert for the same file (same hash) already exists with a shorter route.
  5. If the routing length (TTL) is less than 6 then the advert is sent to all adjacent servers.
NOTE: At some future point the routing character will probably be encrypted with the servers main encryption key before being appended to the route.

File Downloads

  1. When the user requests a file he is really just requesting the first 'header' block identified by the hash value from the File Advertisement. He strips off the first routing character and sends the request to the appropriate adjacent server.
  2. The server receiving the request attaches a character A-P noting which connection the request came from.
  3. If the server receiving the request has the data block in cache it strips off the first character for the return route and sends the data block (with the return route) to the appropriate connection.
  4. Otherwise it strips off the first character of the sending route and sends the request to the appropriate server.
  5. Servers receiving a data block with a return route strip off the first character of that route and send the block to the appropriate adjacent server.
  6. Once the requesting server has the first data block (the 'header') it then gets the block IDs for the rest of the file out of the header block and requests each one in turn.
  7. Once the requesting server has all the blocks for the file, it is reconstructed by joining all the datablocks together and decrypting the file with the key contained in the header block. (NOTE: this decryption is simply there so that if the same file is uploaded twice, all the data blocks have different content hashes... no zero blocks, or duplicates... this is not for security).

The Disk Cache (not really part of the protocol, but what the hell)

The disk cache is just a big ring buffer full of 64Kb data blocks. All blocks are encrypted using a block cipher using a random key. This key is created on startup from user supplied entropy (mouse clicks) and is only stored in memory. Thus, once the program is dead, the key is lost forever in user space (might still be in your swap file or sitting in your unused memory somewhere though :-). Similarly the advert cache file which keeps a list of all the file adverts and the header block ID for each file stores the header block ID encrypted with main random key.

Crypto Stuff

Cipher: Main cipher is a homebrew based on a 20 round version of Wheeler and Needham's XTEA algorithm.
Hash: upper 128bits of RIPEMD-160
D-H: uses the Karatsuba square and multiply method.