As I wrote in the previous post dedicated to the Vanish/Unvanish competition, I was quite lukewarm about the new defensive features proposed by the Vanish team. As the Unvanish team clearly stated, those new features [limit the current aggressive Vuze replication strategy, set a threshold replication factor for each DHT entry, spread the secret key shares among 2 DHTs : OpenDHT and Vuze], for sure it will raise the bar for an attacker [in terms of capability to harvest the DHT] but not that much, or at least far from being in an order of magnitude that can resign anybody/any company/any hacker group to spend their expensive time elsewhere.

That’s something to, in my humble and inexperienced opinion, all what is related on security & privacy is based on the fact that breaking the system should be really more expensive/time & resources consuming than the secret itself. That’s the paradigm of current crypto-systems and especially on key length strategies.  So if this ratio value/time is not that bad, the system cannot be qualified as secure and that’s what the Unvanish team has shown with success.

Based on that, and defensive strategies which rely on the DHT replication strategy seems irrelevant, the figures associated are not as big as needed, even if we talk about 1 million Vuze nodes, regarding the consistent living time of a self-destruct message [currently 8 hours or more using a proxy, but I guess the useable delay in the real world should be something between a week and a month], crawling enough nodes to gather all DHT keys is really not that much [considering the time to break a 128bits AES key for example].

So for a while, I really thought those Unvanish guys were right, as they conclude in their paper :

[…] for the time being, Vanish’s security should be viewed with skepticism. Whether DHTs are the best choice for key-share storage remains an open question.

However, as I don’t like to feel I made a mistake or at least I believed Vanish was a wonderful concept [and for sure Bruce Schneier’s last CryptoGram convinced me a little bit more], I tried to think differently, instead of trying to tweak Vuze to only raise the bar, why not setting the privacy as a requirement for a DHTs and according to this assumption, what could help.

And as a result, one answer is really straight forward [maybe too much… I may have forgotten something], the Vuze DHT is a public DHT, any client can join, participate, get and store data… Nice. But what about adding a new option like be able to get and store data but restricted to a part of the clients and then adding some privacy to what could be propagated among the DHT ?

We can think on some complex protocols and so on but let’s try to keep things simple. For example take the example of a huge tree data structure, if you know the path to access the data you’re looking for, that’s extremely fast, but if you only want to crawl the tree (linearly or not) and expect to find something, it is going to be quite long and cpu intensive.

So based on this simple example, let’s do the same, why not adding a code access to private entries ? Any client which wants to store an entry will add an access code, in the case of Vanish it could be as simple of the original message hashing [SHA1, Skein, any kind of hash function as secure and long enough to discourage brute force attack] and any client which wants to retrieve the entry will have to provide the access key (can be hashed to increase security, as usual), in the case of Vanish the message hashing can be added to the self-destruct message header in addition to the L access key [the n key shares DHT indexes].

It looks simple and effective, isn’t it ?

Like that, only the Vuze clients clients which want to decrypt the VDO will be able to retrieve the key shares, any massive crawling attack [means without any Vanish messages as sources] won’t be able to gather any key shares in a realistic time [else it would require some brute force attack on every entry so logically irrelevant].

This add-on would obviously requires some changes on he current Vuze implementation but compared to the current Vanish proposed features :

  • It is fully backward compatible as that’s a new feature to retrieve DHT entries and the “old” way is still possible for public entries
  • It should be easy to implement, only an access code to store and to check to return the hashtable entry
  • It doesn’t affect the current Vuze reliability and replication strategy
  • It doesn’t change really the public DHT philosophy, in letting Vanish to store key shares, it stores private data and more generally if we hope to use DHTs to enable cloud storage, privacy is needed.