• WinHasher is a Windows applet and command-line program that computes MD5, SHA-1/256/384/512, RIPEMD-160, Whirlpool (2003), and Tiger (1995) hashes of a text string, disk file, or group of files. C# source code available. .NET v2 required.
• WinMD5 is a Windows app that computes the MD5 of a disk file. It needs MD5SUM files to automate file verification. .NET required.
• Crypto Hash Calculator is a portable Windows app that computes the MD-2/4/5, SHA, SSL3, MAC and HMAC of a text string or disk file. Doesn't look like it automates hash comparison.
• digestIT 2004 is a Windows Explorer context menu that calculates the MD5 or SHA-1 hash of a file or files. 64-bit version available.
• WinMd5Sum Portable is a portable Windows app that computes the MD5 of a file via drag-and-drop. Looks like you can paste a comparison hash value in the app for an automated verification.
• Hash on click The freeware version of this context menu add-on can calculate the CRC32, MD5 and SHA-1 of a file. Doesn't look like it automates hash comparison.
• MD5Summer is a stand-alone application that computes MD5 and SHA-1 hashes of a disk file or group of files. Can read/write GNU MD5sum files. Source code available. Developer warns that "this [program] may be buggy". Beta software (3/2011).
• Checksum is a context menu add-on that uses the MD5 and SHA1 hash routines. It's a portable app that can create hashes for files, groups of files, and recurse subdirectories. It also supports file masks (*.mp3), custom mask groups (music=*.mp3,*.wav,*.ogg) and ignore lists. Checksum reads and writes .md5 and .sha files to support file verification and can create .m3u and .pls music playlists. Checksum can also be run from the command-line. Logging of the program's actions is supported. Separate "Hashdrop", "Batch Runner" and "Simple Checksum" programs extend Checksum's functionality by adding batch processing and drag-and-drop support.
• Gizmo Hasher (unrelated to this site) is a Explorer context menu entry that computes SHA-1/256/384/512, CRC-16/32, RIPEMD-128/160, MD-2/4/5, MD2, HAVAL-5-256, HASH-32-5, GHASH-32-3, GOST, SizeHash-32, FCS-16/32 and Tiger hashes of a disk file, group of files, or directory. Can read/write hash values to disk for future verification.
• Nero MD5-Checksum computes the MD5 hash for a file. There's not much information about this utility on the Nero website.
• RapidCRC computes CRC32 and MD5 hashes. Supports file names with embedded CRC32, e.g "MyFile [45DEF3A0].avi". Source code available via CVS. Program is in Beta (3/11).
• Easy Hash is a portable application and Explorer context menu that computes over 130 different hash functions for file directories, individual files and text strings. Compares two directories to find duplicates. It can save generated hashes to .CSV, .HTML, .SFV, .MD5 and .SHA1 file extensions. Can associate itself to .sfv, .md5 and .sha1 files. Can install itself in Total Commander, Unreal Commander and/or Free Commander. Easy Hash can also "reverse hash" CRC-32 hash values, which can be used recover passwords. Claims to reset passwords in MaNDOS, RAdmin, Mantis, Joomla, Wordpress, Mambo, vBulletin, TYPO3, phpBB, Drupal, Prestashop and Magento.
• ExactFile is a Windows application that calculates MD-2/4/5, SHA-1/256/384/512, CRC32, Adler32, GOST, RIPEMD-128/160, TIGER-128/160/192 hashes for files, directories, and optionally subdirectories. The program can be associated with .md5, .sha1 and .sfv file extensions and can use these file formats to verify checksums. A command-line version of the program called EXF is available. Programs are in Beta (3/11).
• ilSFV uses .sfv, .ms5 and .sha1 file extensions to verify file hashes. As of 3/11, website has no WOT rating, so be careful. (3/11)
• Kana Checksum supports the CRC32 and MD5 hash algorithms. It can be used as a stand-alone program or integrated into Explorer as a context menu selection. Supports .md5 and .sfv files.
• Hasher supports the SHA1, MD5, CRC32 and ELF hash algorithms. It can calculate the hash of a file or text string.
• File Verifier ++ supports the CRC16/32, BZIP2 CRC, MPEG2 CRC, JamCRC, Posix CRC, ADLER32, MD4/5, EDONKEY2K, RIPEMD-128/160/256/320, SHA-1/224/256/384/512 and WHIRLPOOL algorithms. It's portable, but can also be integrated in to the Explorer context menu. A command-line version of the program is included. The program can calculate the hash for files, directories, subdirectories, and text strings. File selection can also be done using regular expressions. Can compare hashes to previously calculated values. Website has no WOT rating, so be careful. Beta software (3/11).
• Jacksum is a Java application that can work as a Windows or command-line application. It can also be a "send to" context menu option. It supports 58 hash algorithms and can calculate the hash values of text strings, files, directories and sub-directories. It can write hash values to files (e.g. .md5, .sfv). Java Runtime Environment required. Not sure if/how it compares hash values. Source code available. Informative website.
• MultiHasher supports the CRC32, MD5 and SHA-1/256/384/512 hashing functions. It can calculate hashes for files, multiple files and text strings. Support for .md5 and .sfv files. Program is in Beta (3/11).
• FlyingBit Hash Calculator is an Explorer context menu addition that supports CRC16/32/64, eDonkey/eMule, RIPEMD-160, MD5/MD4, Tiger and SHA-1 algorthims. Reads and writes .md5 files. Website has no WOT rating and Siteadvisor warns of a security risk as of 3/2011, so be careful.
• eXpress CheckSum Verifier (XCSV) & eXpress CheckSum Calculator (XCSC) WOT warns that the website has a poor reputation, so I didn't research these products any further (3/11).

Digitally signing an email message, for example, involves computing a cryptographic hash of the body of the message and all attachments that is then encrypted using the sender's private key. (Note: It is the hash that is encrypted and not the message itself when the message is only digitally signed and not encrypted. When the entire message is encrypted, the recipient's public key is used to do so.) The encrypted hash is then attached to the message for transport. On the receiving end, the digital signature accompanying the message is decrypted using the sender's public key, which could have accompanied the message or could have been drawn from a key escrow, and the resulting data, which was the original hash of the message body with attachments, is compared against a newly computed hash of the received message data. If the original hash and the newly computed one are identical, then there is a high degree of probability that the message was not altered in transit and that it did come from the person whose digital signature accompanied the message.

Another important use for cryptographic hashes is in the verification of an acquired data stream against a published hash for that stream. For example, individuals, companies, and organizations often provide file download services on web sites and in online databases. In addition to offering content in the form of downloadable files, hashes of those files are often published that the consumer can validate the downloaded content against. If the consumer's own computation of the hash of the content using his or her own tool, which can be different from the tool used by the content provider, is identical to the published hash, then there is a high degree of probability that the downloaded content is identical to the published data. This is useful for ensuring that the received file is what was published both from the standpoint of malicious alteration and from the standpoint of accidental alteration or truncation in transit, which is much more likely.

What the hash verification does not do is validate that the acquired data stream is harmless. Because of the ease with which hashes can be computed, malicious web site owner's can publish hashes for infected content. Even "dear john" letters, which might be far from harmless to the recipient, can be digitally signed for email transport. The hashing involved in either case says nothing whatsoever about the nature of the content provided. Unsuspecting consumers might infer trust in the content from the existence of the published hash or digital signature when in fact all the hash can do is facilitate validation that the content received matches the content published. Trust in the content itself must be derived from other knowledge that the consumer/recipient possesses about the publisher/sender.

Suggested further reading, see Cryptographic Hashes: What They Are, and Why You Should be Friends

Virtually all algorithms have gone through revisions or replacements to improve their inherent security (SHA-2, for example, being more cryptographically secure than SHA-1, and the final version of Whirlpool more than earlier versions). In addition, some algorithms, such as SHA and RIPEMD, offer variations that reduce the likelihood of accidental collisions (two messages having the same hash). SHA-512, for example, is SHA-2 with a 512 bit (64 byte) message digest size that reduces the likelihood of accidental collisions versus SHA-256, but a larger digest size does not make an otherwise identical hash algorithm more secure. The larger digest sizes satisfy the needs of encryption algorithms that require them.

The security of a hashing algorithm, however, is defined by its resistance to certain kinds of attacks such as pre-image attacks and deliberate collision attacks irrespective of its digest size. (Digest size merely refers to the number of bits in the hash produced by the algorithm.)

CRC is a high-performance algorithm that can be implemented in hardware for the validation of data moving through the electronics of a computer or network device at high speed. Its purpose is to provide maximum performance in the detection of errors in the data stream. CRC is not suitable for cryptographic use because of its low collision resistance, but it does provide basic error checking when performance is paramount.

The widely-used MD5 algorithm is the latest of a serious of algorithms in the same family. It produces a 128 bit message digest. It has been shown, however, that MD5 is not collision resistant. In 2007, two Danish researchers demonstrated that it is possible for two executable programs, one benign and the other not, to share the same MD5 message digest. It would be difficult for malicious coders to exploit the researchers' methodology because it would require the coders to insinuate themselves into the publication of the original program, but it is difficult to be sure that this could not lead to a practical attack vector. The researchers' conclusion was that MD5 ought not be used for code signing and cryptographic purposes.

SHA was created by the National Security Agency (NSA) of the United States Government, and it has been used as a general purpose algorithm for cryptographic applications since the mid-1990s. (Although hashing algorithms are not reversible encryption systems, they are used by such systems for various purposes.) Weaknesses in early versions, SHA-0 and SHA-1, led to the creation of SHA-2. (SHA-256 and SHA-512 are both SHA-2 algorithms with differing message digest sizes.) A public competition for a successor to SHA-2, which will become SHA-3, is currently being conducted by the National Institute of Standards and Technology (NIST). Among the current SHA algorithms, SHA-256 provides a good compromise between performance and security having no known collision vectors. One of the chief criticisms of SHA-1 and 2, however, has been that their development was conducted by a secret governmental agency.

Unlike SHA, RIPEMD was created by an open academic community--the COSIC group of Belgium's Katholieke Universiteit Leuven, which is the same group whose Rijndael encryption algorithm won the competition for the U.S. Government's Advanced Encryption Standard in 2001. RIPEMD comes in two versions, RIPEMD-128 (the faster) and RIPEMD-160 (the more secure) each of which has an extension for a larger hash result size (256 and 320 bits respectively). RIPEMD creators caution that the larger hash result sizes of the extensions should not be regarded as more secure than the base algorithms and are merely provided for applications that require larger message digests.

The Whirlpool hash algorithm was created by one of the co-creators, Vincent Rijmen, of the Rijndael encryption system that became the Advanced Encryption Standard. Whirlpool is actually based on Rijndael with certain key differences that make it a one-way hashing algorithm instead of a reversible encryption system. Whirlpool, which has a fixed message digest size of 512 bits, has been revised twice to deal with weaknesses found in early versions. These versions are referred to as Whirlpool-0, Whirlpool-T, and then just Whirlpool for the final published version. All implementations are expected to use the final version.

Programs that use any of these algorithms for file validation purposes ought to at least compute MD5 and SHA-1 hashes as these are the most widely used by software publishers. If both are used, the effects of their respective weaknesses can be canceled because it is extremely unlikely that a given malicious file could simultaneously exploit the weaknesses of both. For non-cryptographic purposes, this would be sufficient. Good supplemental algorithms to these would be SHA-256 and Whirlpool as these currently have no known weaknesses. The inclusion of other algorithms does not necessarily make a given program better. There are some differences in the algorithms used by the various programs reviewed here.

The various versions of SHA and RIPEMD and the latest version of Whirlpool are included in the International Standards Organization (ISO) standard 10118-3:2004 for dedicated hash functions.

One-Way Accumulators:

One-Way Accumulators (OWA) offer a decentralized alternative to Digital Signatures. Their advantages include the following:

• Most notably, the main advantage of OWAs over Digital Signatures is that no one need know how to authenticate, sign, or time stamp a message, thereby dispensing with the need for a CA.
• More particularly:
• OWAs allow for a straight-forward and efficient method of producing collective signatures.
• 'Forgery' in the utilization of OWAs is infeasible because the putative forger cannot make a valid time-stamp of a document that was not expected at the time recorded on the stamp. For instance, a student who wishes to plagiarize a paper written on a given date (and so time-stamped) would be unable to change the time-stamp in order to misrepresent their (plagiarized) authorship to pre-date the original's authorship.
• OWAs are no less secure than one-way functions, and indeed many cryptographic protocols are based upon the presupposed 'hardness' of reversing one way functions.
• The relationship between OWAs and One-Way Trapdoor Functions is, at present, unknown.

In conclusion, it would appear that these one-way hash functions offer considerable advantages to traditional methods for authentication, membership testing, and time-stamping.