Hey Everybody,

Sorry about the delay in Dev Blogs — It’s been a snowy/icy week, and folks have been out of the office. I’ve got an update for you now though.

The team is still working on getting documentation and project planning things done. We sat down with our PM and started to formulate a schedule — we now have at least a rough idea of the trajectory of the project. We also got a sense for what sort of people we’d like to hire to assist with this project, and how many of them. This sort of feels like the calm before the storm — meetings, planning, estimating…once the coding starts, we’ll have our noses to the grindstone for some time.

Meanwhile, John and I started hardening the design of the Distributed Hash Table implementation that will be necessary for SDFS’ clients to communicate off the blockchain. Our primary concern with the design was the potential for “griefing” the table — filling it with useless data or deleting data just to be disruptive or to attempt a Denial of Service attack. To secure this potential attack surface, we decided to utilize cryptographic hashing and signing, and a permissions system in which certain operations are only allowed for certain parts of the table, and that each client would be smart enough to know if a requested operation is valid.

One type of information (among others) we will store in the DHT is an encrypted list of Containers that each user is a Member of. It stands to reason that such a list should only be able to be modified by the user the list belongs to (and, because the entries in the list are encrypted with the user’s Public Key, only that user can read from the list as well). Since this is a Hash Table, the user needs to know what key the values exist at — since this user may be logging into a new system for the first time, this key needs to be readily available, so the key is a hash of the user’s address.

“But wait,” you might be thinking, “User addresses are not private, so it is easy for somebody other than the user to access those values.” You’d be correct, but we’ve devised a way to permission modifications to this value. To add a value to a key, a user would have to provide:

Their address, sender

Which key to add a value to, key

The type of message being sent, type

The value to add, value

A digital signature of the request, signature

“Add” in this example, operation

Once a user has calculated this information, they are ready to update the Hash Table…but this table is Distributed, which means keys are scattered across all the nodes in the DHT. Using some backbone DHT operations, the Sending User determines the Key-Holding User can be reached by routing this request through one or more Routing Users. So, the Sending User sends the request to the Routing User.

Once a User receives a message, the first thing they do is validate that the request is valid (this is true for Routing Users as well as for Key-Holding Users). To determine the validity of the above example, the Routing User would execute the following process:

The signature is validated to make sure it correctly matches the content.

The Public Key of the signer is extracted from the signature

The Public Key is used to compute the signer’s address

The hash of the signer’s address is compared with the key that is being modified; if they match, the request is valid — if they do not match, the request is invalid and the Routing User will not forward the request on (nor would a Key-Holding User actually execute the requested operation)

Users will continue to forward this request on, each of them validating it in turn, until eventually the request ends up at the Key-Holding User, who validates it and executes the operation against the DHT. If a User ever encounters an invalid request, the requester can be considered a Bad Actor and Bad Things happen to Bad Actors (we aren’t clear, exactly, what those things should be, but in all likelihood, their future communications will be ignored for some amount of time)

“But what happens if a Bad Actor wants to grief keys for which he is a Key-Holding User” you might counter — we’ve considered that too. First, my explanation above was somewhat simplified — there are actually multiple holders for each key, so if a Bad Actor deletes all the values for the keys they hold, the DHT backbone will simply ask another one of the Key-Holders for the value. They can try to add bad data, but they won’t be able to generate the necessary signature, so when the data is fetched it will be obvious that it is corrupt. To truly damage a key by deleting its values, all Holders would have to be united, but that is very difficult to do. The DHT technology we are currently planning on using is called S/Kademlia (“Secure Kademlia”), which uses a system not unlike Bitcoin’s Proof-of-Work mining algorithm to generate a DHT node ID — to attempt to generate a set of node IDs that would be the only Holders of a particular key would be very (VERY) expensive, and frankly not that useful.

So, there you have it, a secure and permissioned Distributed Hash Table that will enable us to invite new Members to Containers and bootstrap new Nodes. This component is crucial to SDFS, so having a full design for it is a big stride. Tune in next time for more development updates.

About the Author:

Cody Sandwith is a University of Washington graduate, and has been working for Topia Technology since 2011 on Secrata, a highly-encrypted File Sync and Share Platform.