Checksums

You'll see heavy use of checksums throughout OpenBSD — indeed, throughout the entire UNIX world. Elsewhere in this book, I will assume that you can use checksums. If you're completely comfortable with checksums you can skip this section, but if you're the least bit foggy read on.

A checksum is the result of taking a chunk of data, such as a file, and performing complicated mathematical computations on it to produce a short string of characters. ("Short" is a relative term, but even an 80-character result is far shorter than the thousands of lines of source code it might encompass.) The resulting number is called a fingerprint. If the original file changes in any way, even by something as trivial as adding a space or a period, the fingerprint changes.

Checksums give a systems administrator a chance to verify data integrity. Many software distribution sites, including OpenBSD and its mirrors, include checksums for the files that they provide. For example, every OpenBSD architecture release directory includes a file called MD5, which includes MD5 checksums for each of the OpenBSD distribution sets.

Using Checksums

OpenBSD includes tools to calculate MD5, SHA-1, and RMD-160 checksums. The most popular type is MD5, but the others are perfectly valid. Each algorithm is very different and generates a different result. You must use the appropriate tool for the type of checksum you are trying to verify! When you're given a MD5 checksum for a file, for example, computing the RMD-160 checksum for that file really doesn't help much.

If you want to verify the checksum on a file you have downloaded, just run either md5(1), sha1(1), or rmd160(1), giving the filename as an argument. Here, we compute the MD5 checksum for the OpenBSD 3.2 i386 misc32.tgz distribution set:

 # md5 misc32.tgz MD5 (misc32.tgz) = ba112a10afb86c78a19712705a5f476a # 

If you check the MD5 file in the 3.2/i386 directory, you will see that the correct MD5 checksum is, indeed, "ba112a10afb86c78a19712705a5f476a." This file is identical to the one that was used to calculate the checksum.

Non-Matching Checksums

What if the checksum doesn't match? You have a few choices, depending on whether you suspect malice or laziness.

If someone has tampered with the file since the vendor made it available, the checksum will be different. This file may contain a Trojan, backdoor, or some other intruder-friendly poison. Look around for a copy of the file from another mirror site. If all of the distribution files you find have the same non-matching checksum, you may be facing a simple case of distributor sloppiness.

In the free software world, it's not uncommon for a software author to change the software he's distributing without making either a version bump or a checksum update. While the OpenBSD project uses checksums rigorously, and updates them at any excuse, this isn't necessarily the case for other projects. If the checksums don't match, but are consistent across the board, contact the software author or distributor and ask if they forgot to update the checksum file. You may have actually found a trojaned distribution file, however.

If nothing else, you can always closely examine the file for differences from a known-good version of the file, and see what changes have been made. This sort of careful scrutiny found the OpenSSH trojan in 2002.

Note

If someone has compromised a server and replaced a piece of software with a trojaned version, the may well have replaced the checksum file on that server as well. In those places where OpenBSD relies upon checksums from third parties, it includes a known-good check-sum. When in doubt, download the file from one server and the checksum from another!