What's an ed2k hash?
In short, a hash is a checksum. It is used to detect errors in data by checking the integrity of the message/file. There are various different hash algorithms used for differing purposes, some that are focused more on security and some on speed. AniDB sports both kinds; CRC is not particularly secure at all, while MD5, SHA-1 and the MD4/ed2k hashes are much more secure from a cryptographic standpoint. They are not fail-safe though, but having more than one hash makes it exponentially harder to counterfeit a file. You might be able to fool one of the hashes, but generally not two, or as is the case with most of the files found in AniDB: four hashes!
The ed2k hash is based on the md4 algorithm, but rather than providing a single hash of the entire file, it breaks the file up into 9500kb chunks and produces a final hash based on the md4 sums of the chunks. While md4 is no longer considered secure from a cryptographic perspective, for the purpose of uniquely identifying files it's more than adequate. It is often listed as part of an ed2k link, which also includes a size in bytes, and a name.
Why does AniDB require ed2k-hashes?
The main reason for this is that it avoids adding of double database entries. AniDB will not allow you to add a file with the same ed2k-hash as an existing one.
The file size and ed2k-hash of a file is used to identify it globally.
You are allowed to add files without ed2k-hashes to AniDB, however you should edit those files later and add the missing ed2k-hashes. Once you added a certain number of files without ed2k-hashes you may no longer add new files without ed2k-hashes until you edit your old files first.
Why use ed2k instead of another type of hash?
- The combination of ed2k-hash and file size makes ed2k effective for uniquely identifying files.
- Since ed2k-hashes can be passed back and forth within a URI with both the hash and file size in a widely recognized format it is a convenient method for adding or checking files.
- Other hashes are good for validating if a file is corrupt if you already know what file you are comparing it against, but cannot necessarily globally identify a file in the system like the ed2k.
- AniDB was designed around ed2k, although other hashes have been added to the file records for validation, the internal structure is based on ed2k. If the site goes through a complete redesign then maybe another hash will be made the primary hash, but at this point, this is not likely to change.
Which software can be used to generate them?
If you have the file(s) on your hard disk or on CD you can use all kinds of tools to generate the ed2k-hash and other additional info:
- Avdump3 is the preferred tool as it can automatically creq files.
- AniDB O'Matic by BennieB/PetriW can generate ed2k-hashes. It generates ed2k-hashes, md5, sha-1, crc32 in one go and also lists stuff like codec, resolution, bitrates, ...
- ed2k_hash another tool which is commandline based (current Windows and OSX versions have a GUI as well) and also available for Unix operating systems (Linux/BSD/etc).
- Filehash a little Java program written by Malich. For further info on it read here (old forum)
- Hashcalc can create md5, sha-1, crc32, ed2k-hashes and various other hashes in 1 go.
- RHash multiplatform open source console utility for computing md5/sha1/crc32 hashes, EDonkey and Magnet links for a directory tree.
How is an ed2k hash calculated exactly?
A file is hashed in 9728000 byte chunks, using the md4 algorithm, and produces a 128 bit hash for each chunk. For files with only one chunk, the ed2k hash is the md4 of the file, however for hashes with 2 or more chunks the the hash of each chunk is appended to those before it, and an further md4 of the hashes themselves provides the ed2k hash of the file. Pseudo code is given below:
- if filesize is less than or equal to 9728000:
- return md4 of file
- for chunk of size upto 9728000 in file:
- append md4 of chunk to hashlist
- if filesize is a multiple of 9728000:
- append md4 of null to hashlist
- return md4 of hashlist
Note that there are two different ways in practice that implementations treat the 9728000 byte boundary, given as either the red code or the blue code above, black is common to both. In practice this difference only affects a tiny number of files, however is the one case where two 'valid' ed2k hashes might be produced from one file. See forum topic 1 on this issue as well.
List of which clients use which method
- edonkey2000 v0.5.0 to v1.4.3
- mldonkey (220.127.116.11 tested)
- shareaza (1.8 tested)
- HashCalc Version (2.01 tested)
- edonkey-tool-hash (0.4.0 tested)
- fsum (2.51 tested)
- ed2k_hash (0.4.0 tested)
- hashgen (0.0.6 tested)
- edonkey2000 until v0.5.0
- emule (0.46c tested)
- AOM (0.5.5.239 tested)
- webaom (v1.13 tested)
- ed2k code by Stephane D'Alu (1.4 tested)
- jacksum (1.7.0 tested)
- rhash (1.1.9 tested)
List of affected files, by fileID
|File||Size (bytes)||Blue method||Red method|
|File of zeros||9728000||d7def262a127cd79096a108e7a9fc138||fc21d9af828f92a8df64beac3357425d|
|File of zeros||19456000||194ee9e4fa79b2ee9f8829284c466051||114b21c63a74b6ca922291a11177dd5c|