3 ms·

I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? MD5 is clearly just a checksum now, sin

I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? MD5 is clearly just a checksum now, since it's not secure, but it was designed to be originally. And would you ever want to use a checksum that others could manipulate at will? Curious. I feel like the line between "this is a checksum" and "this is a secure hash" is kind of illusory, other than for pure performance reasons.

JoachimSchipper 14y ago
E.g. ZFS uses non-cryptographical hashes to detect bitrot. TCP and IPv4 use a non-cryptographical hash to detect packet corruption. Etc.
- codinghorror 14y ago
  terminology issue, I guess, I'd call those checksums -- where speed is the overriding concern and you're not worried about attackers changing the data underneath you. (And you actually need to uniquely identify the data in a reliable way..)
  - scott_s 14y ago
    Sure, it's a terminology issue, but as several others have pointed out, you're the only one using your terminology. So expect people to be confused when you try to explain these things using your definitions.
    - parenthephobia 14y ago
      In the case of TCP/IP, everyone calls the checksum a checksum, and nobody calls it a hash.
masklinn 14y ago
> I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? Sufficient. all hashes (cryptographically secure or not) will fail to detect some changes, that's a hash collision and that's an intrinsic and non-negotiable property of m:n mappings where len(m) > len(n). "Checksums" assume there is no attack being performed, as in nobody is trying to craft a collision. In "normal operations", even with pretty shitty hash functions (e.g. CRCs) hash collisions between subsequent file changes (or whatevere) are unlikely enough.

3 ms·

I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? MD5 is clearly just a checksum now, sin

by codinghorror 14y ago

JoachimSchipper 14y ago
E.g. ZFS uses non-cryptographical hashes to detect bitrot. TCP and IPv4 use a non-cryptographical hash to detect packet corruption. Etc.
- codinghorror 14y ago
  terminology issue, I guess, I'd call those checksums -- where speed is the overriding concern and you're not worried about attackers changing the data underneath you. (And you actually need to uniquely identify the data in a reliable way..)
  - scott_s 14y ago
    Sure, it's a terminology issue, but as several others have pointed out, you're the only one using your terminology. So expect people to be confused when you try to explain these things using your definitions.
    - parenthephobia 14y ago
      In the case of TCP/IP, everyone calls the checksum a checksum, and nobody calls it a hash.
masklinn 14y ago
> I guess, but what's the value of a "checksum" that fails to detect certain "cryptographically secure" changes in a file? Sufficient. all hashes (cryptographically secure or not) will fail to detect some changes, that's a hash collision and that's an intrinsic and non-negotiable property of m:n mappings where len(m) > len(n). "Checksums" assume there is no attack being performed, as in nobody is trying to craft a collision. In "normal operations", even with pretty shitty hash functions (e.g. CRCs) hash collisions between subsequent file changes (or whatevere) are unlikely enough.