Donovan Baarda | 21 Feb 2006 13:07
Picon
Picon
Gravatar

Re: librsync 4GB bug

G'day Dave,

Note we are using the sourceforge lists/trackers/CVS etc. I'd suggest
subscribing to at least librsync-devel if you are doing devel work.
Cc'ing this to the devel list...

On Tue, 2006-02-21 at 21:51 +1100, dave kempe wrote:
> Hi Donovan,
> we have a guy working for the dole over here (under the community code 
> project - http://www.communitycode.org (site might be down atm).
> Anyway, he has being trying to slowly fix the librsync files over 4GB 
> bug which you can replicate using the simple tests like from this email:
> 
> http://lists.gnu.org/archive/html/rdiff-backup-users/2006-02/msg00015.html

Excellent!!! 

> Anyway, he seems to be finished - I think he used some MD4 bits from the 
> openssl libraries, and I have told him to post them to librsync-devel.
> I hope you haven't gone off and solved it all already, and of course I 
> would appreciate a once over of his code if you have time.
> It might be few days before its ready for a diff/patch submission yet.
> Its seems to work....

Get him to post the patch up on SF. I can also add him as a developer
and give him CVS access if he wants, but it's probably a good idea to
post this stuff initially as a patch so we can go over it before
committing it.

I did have plans to switch to using libmd, openssl, or our own md4sum
(Continue reading)

Donovan Baarda | 21 Feb 2006 14:13
Picon
Picon
Gravatar

Re: Re: librsync 4GB bug

On Tue, 2006-02-21 at 12:07 +0000, Donovan Baarda wrote:
[...]
> On Tue, 2006-02-21 at 21:51 +1100, dave kempe wrote:
> > Hi Donovan,
> > we have a guy working for the dole over here (under the community code 
> > project - http://www.communitycode.org (site might be down atm).
> > Anyway, he has being trying to slowly fix the librsync files over 4GB 
> > bug which you can replicate using the simple tests like from this email:
> > 
> > http://lists.gnu.org/archive/html/rdiff-backup-users/2006-02/msg00015.html
> 
> Excellent!!! 
> 
> > Anyway, he seems to be finished - I think he used some MD4 bits from the 
> > openssl libraries, and I have told him to post them to librsync-devel.
> > I hope you haven't gone off and solved it all already, and of course I 
> > would appreciate a once over of his code if you have time.
> > It might be few days before its ready for a diff/patch submission yet.
> > Its seems to work....

Note that I don't know if that bug has anything to do with md4sum's at
all... 

--

-- 
Donovan Baarda <abo <at> minkirri.apana.org.au>
http://minkirri.apana.org.au/~abo/

-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
(Continue reading)

Don Malcolm | 27 Feb 2006 06:32

'internal error: job made no progress' on 25G file - Bug Request ID: 1110812

There is a small patch file for Bug Request ID: 1110812 available in
Patch Tracker ID: 1439412.

The error 'internal error: job made no progress' occured on files over
4Gig in size.

https://sourceforge.net/tracker/index.php?func=detail&aid=1439412&group_id=56125&atid=479441

Don Malcolm

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
Donovan Baarda | 1 Mar 2006 17:29
Picon
Picon
Gravatar

Re: [librsync-users] MD4 second-preimage attack

On Tue, 2006-02-21 at 14:58 -0800, rsync2eran <at> tromer.org wrote:
> Hi,
> 
> A year ago we discussed the strength of the MD4 hash used by rsync and
> librsync, and one of the points mentioned was that only collision
> attacks are known on MD4. Well, a recent paper by Wang et al [1] shows a
> several second preimage attacks. First, there's an algorithm which,
> given a random message and its MD4 hash, finds another message having
> the same hash with probability 2^-56. Second, if the attacker can also
> alter the original message (and thus its hash) slightly, he can find a
> second message having the same hash with just 2^27 MD4 invocations.

For the record, here it is in the SF mailarchive.

http://sourceforge.net/mailarchive/forum.php?forum_id=29760&max_rows=25&style=flat&viewmonth=200404&viewday=5

If I understand correctly, provided we add random seeds for blocksums,
these weaknesses would only make attack case 4) easier.

> Doubtless, even stronger attacks will soon be found.
> 
> MD4 (with known seed) is thus completely broken, making rsync batch mode
> and librsync unsafe to use in malicious environments. Please do consider
> phasing out MD4.

Remember we only use a small part of the md4sum for the "strong
blocksum", and hence are already using less than the full md4sum. We
don't really need that many bits of hash for the blocksum. The important
thing for the blocksum is speed. I think md4 + random seed is pretty
much the best "useful hash bits per second" for blocksums. We can adjust
(Continue reading)


Gmane