RHash: many message digests, magnet links and SFV files from one pass

One traversal, many digests, and the formats around them

RHash, the Recursive Hasher, is a console utility for calculating and verifying magnet links and a long list of message digests. The problem it addresses is mundane and permanent: large volumes of data need to be checked for integrity over long periods of storage or transfer, and the tools available rarely agree on the algorithm.

The design decision that makes RHash useful is that one traversal produces several digests at once. The program features list states that it calculates several message digests in a single pass, and that it can process directories recursively. That difference matters on a large archive, where re-reading every file for each algorithm is the difference between one disk pass and five.

Around the digests sit the file formats people actually keep. RHash outputs in a predefined SFV, BSD-like format or in a user-defined one, calculates magnet links, and updates hash files by adding digests for files that are missing from the hash file. So it covers the verification side and the catalogue-building side with the same binary, and portability is explicit: the program is described as working the same on Linux, Unix, macOS or Windows.

The algorithm list reaches past SHA-2 into the exotic

The README lists the supported message digests, and the list is where this tool separates itself from the usual suspects. Alongside CRC32, CRC32C, MD4, MD5, SHA1, SHA256, SHA512 and SHA3 there is AICH, ED2K, DC++ TTH, BitTorrent BTIH, Tiger, GOST R 34.11-94, GOST R 34.11-2012, RIPEMD-160, HAS-160, EDON-R and Whirlpool.

Several of those exist for reasons that have nothing to do with modern integrity checking. ED2K, DC++ TTH and BitTorrent BTIH are the identifiers of older peer to peer networks, and they show up in catalogues of files distributed that way. The two GOST variants are the Russian standard family, and the README links to the ECRYPT Hash Function Zoo and to ECRYPT benchmarking results as external references for the algorithms.

The source layout mirrors the list, with a file per algorithm inside the librhash directory, including gost12, gost94, ed2k, edonr, has160, snefru, tiger and the blake2 and blake3 families. Two files in that list are worth a closer look for anyone reasoning about performance: plug_openssl.c, an OpenSSL plug-in, and sha_ni.c, a SHA implementation built around hardware instructions.

Building with configure and make, and the wrapper that hides it

Installation for a Unix-like system is one line, taken from the README:

./configure && make install

For anything less standard, the README points at the INSTALL.md file in the repository root. The build is a classic autotools style setup with a configure script at the root and a Makefile that starts by including config.mak, so the configure step is what produces the configuration the Makefile reads. The Makefile also lists the platform sources, the header set, and the files that make up the distribution, including the manual page sources dist/rhash.1.in and dist/rhash.spec.in for packaging and the Windows batch helpers dist/MD5.bat and dist/magnet.bat.

On Windows there is a separate path. The repository carries build/vc-2010/rhash.vcxproj, a Visual Studio project for the compiler version its name implies, and binary Windows releases are published on the sourceforge project files area, while official releases are published on GitHub. Two channels for Windows binaries and a source-only Unix build is a mildly confusing arrangement, so check which one you are actually installing.

Magnet links, SFV files and hash file maintenance

Three workflows in the feature list are worth separating, because they answer different needs.

Magnet link calculation is the one with the most visible output. A magnet link encodes the digest of a file inside a link, so a single string can carry both the location and the checksum. That is the format people paste into a torrent client or a chat message, and RHash computes it as a first class output rather than something you assemble by hand from a hex digest.

The SFV format, described in the README as a predefined BSD-like format, is the older list file used for release archives, one line per file. RHash can write that predefined format or a format you define yourself, which covers both the case where a specific tool expects the layout and the case where your own pipeline wants a different one.

The third workflow is maintenance rather than generation. RHash can update an existing hash file by adding the digests of files that are missing from it. For a release that has grown since the first pass, that means adding new entries without re-verifying and rewriting the ones already listed. The repository ships a test suite alongside the code, with tests/test_rhash.sh and a tests/test1K.data fixture, which is where to look when a behaviour differs between platforms.

One library, one command line tool, several language bindings

The repository is bigger than a single binary. The librhash directory holds the implementation of every algorithm and the core hashing interface, and the README links to separate LibRHash library documentation in docs/LIBRHASH.md. The command line front end lives in the root C files, where calc_sums, hash_update, hash_print, hash_check, file_set, file_mask, find_file, output and parse_cmdline split the work between computing, formatting, verifying and selecting files.

There is also a bindings directory at the root, which indicates that the library is meant to be called from other languages rather than only from the shell, and a po directory holding translation files, with librhash/rhash.pot listed as the translation template. The dist directory carries a rhashrc.sample, so a configuration file exists for the tool even though the README does not explain what it can hold.

That is the documentation gap to be aware of. The README is short and points at INSTALL.md, the LibRHash documentation, the ChangeLog and the contribution guidelines in docs/CONTRIBUTING.md, and it links to a wiki table of supported hash functions and to the sourceforge project page. Behaviour that is not in those files, including the configuration options, is yours to discover from the sample file.

Digests are not signatures, and that is the boundary

It is worth being blunt about what RHash does not do. The README describes message digests for verifying integrity, magnet links and hash files, and nothing in it describes signature verification, key management or anything resembling a trust decision. A digest proves that a file matches a hash someone gave you, and says nothing about who produced that hash. If your workflow needs authenticity rather than integrity, this tool answers a different question.

The other boundary is scope of input. The features list talks about processing directories recursively and updating hash files, which makes this a file-and-directory tool. There is no indication in the README that it digests streams from a pipe or a device, so if your data arrives as a stream, plan on writing it to a file first.

For comparison, the alternative approach most teams reach for first is to call the digest utilities that ship with the operating system. Those handle one or two well known algorithms per invocation, produce plain hex output and do nothing else, so a workflow that needs BitTorrent BTIH, ED2K, EDON-R or Whirlpool has no standard tool to call, and a workflow that wants magnet links or an SFV file has to assemble the format itself. RHash exists precisely because of that gap, and the cost of closing it is one dependency with a permissive licence and a long history of small releases.

A once a year release cadence with faster moving commits

The maintenance picture is the last thing to weigh. The repository is not archived and the last push was on 2026-10-19, so work continues. The published releases are much older: v1.4.6 from 2025-05-13, v1.4.5 from 2024-10-14 and v1.4.4 from 2023-07-14. That is roughly one release a year with an occasional longer gap.

So the source tree moves faster than the packaged binaries. Anything committed after the v1.4.6 tag is available only if you build from source, and for a tool that people drop into a pipeline, that gap matters more than it would for a library with a faster release habit.

The licence removes one common objection. The README states that the code is distributed under the BSD Zero Clause License, with the text in the COPYING file at the repository root. A zero clause licence is about as permissive as open source licensing gets, with none of the copyleft or attribution conditions that make teams hesitate over a utility, though your own legal review should confirm how it fits your distribution model.

Editorial conclusion

Adopt RHash when you verify or catalogue large file collections and need digests that the platform utilities do not cover, such as BitTorrent BTIH, ED2K, DC++ TTH or the GOST family, or when you need magnet links and SFV output from the same tool. Do not adopt it as a signature checker or a password hashing tool, because the README describes digests only, and treat the configuration file as undocumented since the repository ships a sample without explaining the options. Verify first which version you are running against the v1.4.6 release from 2025-05-13, since the last push was on 2026-10-19 and the changes since that tag are not covered by a published release.

Frequently asked questions

Official sources

1. License: 0BSD
2. Project website
3. README
4. Releases
5. rhash/RHash on GitHub