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.
> 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.
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..)
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.
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.