Brian J. Beesley wrote:
On Thursday 23 June 2005 17:41, Paweł 'Róża' Różański wrote:
But first, they're [MD5 checksums] put there to check if the file was
downloaded
correctly, not to check, if it's unchanged.
Eh? A complete but incorrectly copied file is very improbable, unless the
software is broken - TCP provides plenty of safeguards against data
corruption in transit.
Do you speak as an expert TCP/IP implementor, or do you speak as an
individual
with "some" knowledge of the protocols involved? I cannot speak as an
individual
with expert knowledge, but the knowledge I have leads me to the opinion
that TCP/IP
does not provide "plenty" of safeguards, or even "adequate" safeguards
for large
file transfers.
I have myself personal knowledge of other protocols which use the same
"checksum" used
in TCP which I have personally seen deliver corrupted messages without any
notification, having been involved in the testing of implementations of
those
protocols. The "checksum" used in TCP is 16 bits. Not what I call "plenty"
of safeguards, especially since it's on a per-packet basis.
Anyway, I use MD5 to check file integrity on a regular basis. A few
months ago, I found
that a download of one of the Fedora Core 3 ISO images I did completed,
but failed
MD5. This is perhaps more to the point, I suppose, since it's not a
"similar" protocol
using the same "checksum", but exactly TCP/IP.
YMMV
As far as I'm concerned the purpose of providing checksums is to verify that
the file downloaded has not been tampered with. Otherwise why go to the
bother of using MD5 - CRC32 is plenty good enough for a quick practical check
that two files which are supposed to be identical really are.
I'm sure many people use many techniques for various reasons. I don't
understand your
characterization of "bother of using MD5" while seemingly holding the
opinion that
running a different program to compute CRC32 is less bothersome. Either
is equally
bothersome to me. Running one program versus another is no bother. The
bother
to me is running any program at all. If I'm going to run any program,
then which one
is irrelevant to me, from the standpoint of bother. Any implementation
is going to
be I/O bound, not compute bound, so speed of the check is also irrelevant.
Second, changing zip's md5
shouldn't be so easy, because one has got to find content, that has
specified md5 sum after being ziped (zip has its own checksum, so I
belive it's impossible to change just a few bytes of zip archive).
The internal checksums in zip format file are either CRC16 or CRC32 which are
almost trivial to forge, given the amount of computer power required to
create a MD5 or SHA-1 hash collision. (Zip was invented before MD5 or SHA-1
and requires to maintain backward compatibility). CRC16/32 are reasonable for
checking subfile integrity but are no safeguard at all against deliberate
tampering. If I wanted to forge a MD5 checksum on a subfile contained in a
zip archive, I'd simply alter the subfile and rebuild the archive adding an
extra subfile whose contents I could vary at will to achieve the required MD5
checksum of the whole archive.
[snip]
Hmm. I thought he said that he wanted to verify file integrity, not detect
malicious tampering. But the topic did change a little. OTOH, you did
not address his point. He didn't claim that one couldn't replace a file in
a ZIP and add another one to cover up, he claimed one couldn't change
just a few bytes, leaving the MD5 the same. I suspect he's correct.
Even adding a new file which would, after compression, yield the same
message digest would be quite difficult. Not because of the compression,
but because of the search space of the message digest. If that were not
true,
then the message digest would never have been accepted in the first place.
Even today, single DES with only 56 bits takes an inordinate amount of time
to break for the casual breaker. Yes, it's no longer considered secure for
bank transfers, 3-DES being recommended until IDEA get's more widely
spread, but for casual use DES is still fine.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
_______________________________________________
Prime mailing list
[email protected]
http://hogranch.com/mailman/listinfo/prime
