Blue Boar <BlueBoarat_private> wrote: > I had been under the impression that Kazaa DID use checksums, just that it > had some sort of bug, or was trusting the peers, or something. I thought > that was what the temp filename was. (I wouldn't mind someone pointing me > to any good info about the protocol.) The best source for information about the FastTrack protocol are the old giFT sources (http://www.giftproject.org, they now use their own protocol, get old sources from cvs). Since this is pretty old (September 2001) Kazaa may use a different method for checksumming now but I'll describe how it worked back then. First it does a MD5 hash of the first 307200 bytes (300K) of the file. This is the same thing napster did IIRC. Second it takes 307200 byte chunks from the file and passes them to a algorithm that produces a 4 byte hash using a hardcoded table. The first chunk is taken from file offset 0x100000 (1M) and then the offset is shifted left by 1 bit for the next chunk, etc. The MD5 hash and the 4 byte hash are concatenated to form a 20 byte file id which is used to distinguish files on the network (and group search results, for example). Naturally this method is not cryptographically secure and my guess is that it was choosen for performance reasons. For downloading a file a third hash with a length of 2 bytes is used. Again using a constant table it is calculated from the 20 byte file id and appended to the http url which is used to download the file. As for the possibility of corrupting the Kazaa binary itself I have no experimental data on this. But since performance is not an issue here and it's a special case where they execute the binary automatically I hope they have included a final MD5 check of the entire file against a hash downloaded from their central web page. Hope this helps, Markus Kern
This archive was generated by hypermail 2b30 : Fri Mar 07 2003 - 08:30:21 PST