It can go both ways. If the file's corrupt because either the hash was
modified and the data were intact, OR if the data (plus/minus the hash)
were modified, it's still bad.
Then again, keeping an external hash in another file may allow one to
determine whether the data, or the hash were modified.
The benefits derive, IMO, from the point of view of data source. If you
control the data, and you're concerned about programmatical mods causing
problems, the external method has benefits.
If you're concerned about data security and integrity, the former
approach, allowing you to simply say, "It's bogus, let's attempt to get
it from another source," has promise.
For simplicity, I'd agree that a separate file approach is an acceptable
one.
gerry
Russ Rew wrote:
I wrote:
I think there are some good reasons to keep hashes such as MD5 or
SHA-1 external to files they are intended to check, rather than
embedded in the files:
- If the digest is external, then something that corrupts the file
might also corrupt the digest.
which makes no sense. What I meant to say was
- If the hash is embedded in the file and doesn't agree with the
file contents, it's not clear whether the file or the hash or both
were corrupted.
This is fairly minor, since a mismatch would tell you not to trust the
data in any case. But I still think keeping the hash separate from
the original file makes it easier to compute.
--Russ
--
Gerry Creager -- gerry.creager@xxxxxxxx
Texas Mesonet -- AATLT, Texas A&M University
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843
