Bug 2000 - mdfour.c calculates wrong result when block is a multiple of 64 bytes long.
Summary: mdfour.c calculates wrong result when block is a multiple of 64 bytes long.
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.3
Hardware: All Linux
: P3 minor (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2004-11-04 16:06 UTC by Colin Phipps
Modified: 2006-03-14 08:32 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Colin Phipps 2004-11-04 16:06:30 UTC
Purely technical, but it looks like lib/mdfour.c gets the MD4 checksum wrong
when the block is an exact multiple of 64 - it never calls mdfour_tail, so the
message length is not added to the checksummed data. Compiling mdfour.c with
TEST_MDFOUR and comparing the hashes with the output of openssl md4 on a 64 byte
file shows the bug easily.

Since rsync doesn't require the cryptographic strength of md4 anyway, perhaps it
simply doesn't matter - but it would be good for the file to carry a comment
saying that it is not MD4, if that is the intention.

@@ -166,8 +166,6 @@
        m = md;
-       if (n == 0) mdfour_tail(in, n);
        while (n >= 64) {
                copy64(M, in);
@@ -179,7 +177,7 @@
-       if (n) mdfour_tail(in, n);
+       mdfour_tail(in, n);
(except obviously you need to be backward compatible!)
Comment 1 Wayne Davison 2005-01-10 13:53:40 UTC
The bug with 64-byte-multiple files was fixed for protocol 27 and beyond, which
is testable by putting some debug code into checksum.c directly.  However, the
test function in mdfour.c was not updated to reflect this fix, so it continued
to output the bogus MD4 checksums that were sent for older protocol versions.

I checked-in a fix for the debug function in mdfour.c so that it will output the
right values when TEST_MDFOUR is defined.
Comment 2 Björn Jacke 2006-03-14 08:32:19 UTC
Test  ようこそ