Future DC seek secure and nice hash for identification
June 3, 2007 Leave a comment
By now, you’ve probably not missed that we’re using T(iger)T(ree)H(ashes). Using a hash is incredibly much more useful than going by file name (and size).
While hashes has gotten its fair share of admirers, it sure has gotten its fair share of people who are dismayed about them. The reason I most see is that the people are complaining about the “long” hash time.
I doubt anyone can make your drive go faster to hash faster, but there are other things we can do.
TTHs are getting deeper and deeper buried in DC++, ADC and the entire network that is DC. There is a large problem with this situation, I’m afraid.
The problem is that algorithms like TTH are constantly under attack by cryptographers. These are people who are trying to find out a way to create the ultimate and unbreakable hash, by also trying to destroy current ones.
This mean that there’s a possibilty that Tiger tree hashes are enheritly “broken”. This in turn would mean that malicious people would try and infect the network with incorrect TTHs, and causing quite a nuisance for a lot of people.
There’s a… well, sort of… solution. The solution would be to use multiple hashes. Different algorithms, that is, that are different enough from TTH, but similar enough that the idea is to uniquely identify a file.
A known scheme for indexing files in a hub, would be to use a bloom filter. For this scheme to work nicely would be to use multiple hash algorithms – at the same time. This might be quite expensive, for both hubs and clients. (If not in term of bandwidth, then in terms of CPU usage.)
Another intresting scheme would be to use SET, though I don’t know how easy it would be to use it in DC. As far as I know, it’s also relatively new, so it might be dangerous to jump on the band wagon just yet.
In any case, I think we need to focus attention on the fact that Tiger Tree possibly won’t always be secure enough to use. Before people start writing client and hubs, one must consider that TTH won’t always be used.
As a sidenote to, DC++ will have a hard to adjusting if another algorithm is to be used, but I guess we’ll have to worry about it then, unless someone now write a patch to abstract it away. ;)