You can use a 16-bit truncation of MD5 or SHA-1 or SHA-256 or SHAKE128 as a checksum, but it's not a good checksum.

Why not? Let's model them by a uniform random function of $t$ bits, which is a reasonable model in this scenario. In this case, $\Pr[H(x) = h] = 1/2^t$ for any message $x$ and hash $h$, and every $H(x)$ is independent for each distinct $x$. Thus, the probability of failing to detect an error $e$ in a message $x$ is $\Pr[H(x + e) = H(x)] = 1/2^t$ for any message $x$ and any error $e$. This is the best error detection you can hope for from a hash function designed like a random oracle (or close to it, length extensions notwithstanding).

If you choose a good 16-bit CRC (preprint, paywall-free; web site), then you can be guaranteed:

• any error of odd parity will be detected, provided the generator polynomial has $x + 1$ as a factor;
• any burst error of up to 16 bits will be detected, except an error of the generator polynomial itself, provided the generator polynomial does not have $x$ as a factor (i.e., has a nonzero constant term);
• many errors of up to a certain Hamming weights in data words of up to a certain size will be detected.

Cryptographic hash functions designed for random oracle use like MD5, SHA-1, SHA-256, SHAKE128, etc., guarantee none of these. They're also often much more expensive to compute than error-detecting codes like checksums, because you're paying an extremely high cost for collision resistance which is of no concern for error detection.

1. What are the consequences of simply taking a "substring" of a checksum? I assume, perhaps naively, that it would just increase the likelihood of a collision.

Collisions are not relevant here. The only thing that is relevant is the probability of error detection. Any substring of MD5 or SHA-1 or SHA-256 or SHAKE128 is as good as any other.

2. Is there any reason to prefer taking the last x bits instead of the first x bits, or vice versa?

No. If this led to an appreciably different probability of error detection, then that would be a noteworthy result about the hash function.

3. When truncating a checksum like this, does SHA actually perform any better than MD5? Keeping in mind I am concerned with errors, not attackers.

No. They're both bad choices for detecting independent random bit errors.

You can use a 16-bit truncation of MD5 or SHA-1 or SHA-256 or SHAKE128 as a checksum, but it's not a good checksum.

Why not? Let's model them by a uniform random function of $t$ bits, which is a reasonable model in this scenario. In this case, $\Pr[H(x) = h] = 1/2^t$ for any message $x$ and hash $h$, and every $H(x)$ is independent for each distinct $x$. Thus, the probability of failing to detect an error $e$ in a message $x$ is $\Pr[H(x + e) = H(x)] = 1/2^t$ for any message $x$ and any error $e$. This is the best error detection you can hope for from a hash function designed like a random oracle (or close to it, length extensions notwithstanding).

If you choose a good 16-bit CRC (preprint, paywall-free; web site), then you can be guaranteed:

• any error of odd parity will be detected, provided the generator polynomial has $x + 1$ as a factor;
• any burst error of up to 16 bits will be detected, except an error of the generator polynomial itself, provided the generator polynomial does not have $x$ as a factor (i.e., has a nonzero constant term);
• many errors of up to a certain Hamming weights in data words of up to a certain size will be detected.

Cryptographic hash functions designed for random oracle use like MD5, SHA-1, SHA-256, SHAKE128, etc., guarantee none of these. They're also often much more expensive to compute than error-detecting codes like checksums, because you're paying an extremely high cost for collision resistance which is of no concern for error detection.

1. What are the consequences of simply taking a "substring" of a checksum? I assume, perhaps naively, that it would just increase the likelihood of a collision.

Collisions are not relevant here. The only thing that is relevant is the probability of error detection. Any substring of MD5 or SHA-1 or SHA-256 or SHAKE128 is as good as any other.

2. Is there any reason to prefer taking the last x bits instead of the first x bits, or vice versa?

No. If this led to an appreciably different probability of error detection, then that would be a noteworthy result about the hash function.

3. When truncating a checksum like this, does SHA actually perform any better than MD5? Keeping in mind I am concerned with errors, not attackers.

No. They're both bad choices for detecting independent random bit errors.

You can use a 16-bit truncation of MD5 or SHA-1 or SHA-256 or SHAKE128 as a checksum, but it's not a good checksum.

Why not? Let's model them by a uniform random function of $t$ bits, which is a reasonable model in this scenario. In this case, $\Pr[H(x) = h] = 1/2^t$ for any message $x$ and hash $h$, and every $H(x)$ is independent for each distinct $x$. Thus, the probability of failing to detect an error $e$ in a message $x$ is $\Pr[H(x + e) = H(x)] = 1/2^t$ for any message $x$ and any error $e$. This is the best error detection you can hope for from a hash function designed like a random oracle (or close to it, length extensions notwithstanding).

If you choose a good 16-bit CRC (preprint, paywall-free; web site), then you can be guaranteed:

• any error of odd parity will be detected, provided the generator polynomial has $x + 1$ as a factor;
• any burst error of up to 16 bits will be detected, except an error of the generator polynomial itself, provided the generator polynomial does not have $x$ as a factor (i.e., has a nonzero constant term);
• many errors of up to a certain Hamming weights in data words of up to a certain size will be detected.

Cryptographic hash functions designed for random oracle use like MD5, SHA-1, SHA-256, SHAKE128, etc., guarantee none of these.

1. What are the consequences of simply taking a "substring" of a checksum? I assume, perhaps naively, that it would just increase the likelihood of a collision.

Collisions are not relevant here. The only thing that is relevant is the probability of error detection. Any substring of MD5 or SHA-1 or SHA-256 or SHAKE128 is as good as any other.

2. Is there any reason to prefer taking the last x bits instead of the first x bits, or vice versa?*

No. If this led to an appreciably different probability of error detection, then that would be a noteworthy result about the hash function.

3. When truncating a checksum like this, does SHA actually perform any better than MD5? Keeping in mind I am concerned with errors, not attackers.

No. They're both bad choices for detecting independent random bit errors.

You can use a 16-bit truncation of MD5 or SHA-1 or SHA-256 or SHAKE128 as a checksum, but it's not a good checksum.

Why not? Let's model them by a uniform random function of $t$ bits, which is a reasonable model in this scenario. In this case, $\Pr[H(x) = h] = 1/2^t$ for any message $x$ and hash $h$, and every $H(x)$ is independent for each distinct $x$. Thus, the probability of failing to detect an error $e$ in a message $x$ is $\Pr[H(x + e) = H(x)] = 1/2^t$ for any message $x$ and any error $e$. This is the best error detection you can hope for from a hash function designed like a random oracle (or close to it, length extensions notwithstanding).

If you choose a good 16-bit CRC (preprint, paywall-free; web site), then you can be guaranteed:

• any error of odd parity will be detected, provided the generator polynomial has $x + 1$ as a factor;
• any burst error of up to 16 bits will be detected, except an error of the generator polynomial itself, provided the generator polynomial does not have $x$ as a factor (i.e., has a nonzero constant term);
• many errors of up to a certain Hamming weights in data words of up to a certain size will be detected.

Cryptographic hash functions designed for random oracle use like MD5, SHA-1, SHA-256, SHAKE128, etc., guarantee none of these. They're also often much more expensive to compute than error-detecting codes like checksums, because you're paying an extremely high cost for collision resistance which is of no concern for error detection.

1. What are the consequences of simply taking a "substring" of a checksum? I assume, perhaps naively, that it would just increase the likelihood of a collision.

Collisions are not relevant here. The only thing that is relevant is the probability of error detection. Any substring of MD5 or SHA-1 or SHA-256 or SHAKE128 is as good as any other.

2. Is there any reason to prefer taking the last x bits instead of the first x bits, or vice versa?

No. If this led to an appreciably different probability of error detection, then that would be a noteworthy result about the hash function.

3. When truncating a checksum like this, does SHA actually perform any better than MD5? Keeping in mind I am concerned with errors, not attackers.

No. They're both bad choices for detecting independent random bit errors.