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

Permalink | Reply | 2 comments |
headers
rsync2eran | 4 Mar 2006 15:30

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

Hi,

On 2006-03-01 18:29, Donovan Baarda wrote:
> 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.

It indeed affects only case 4, regardless of seek randomization.

>> 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.
>  
> If someone can provide detailed evidence that some other algorithm
> provides more useful-hash-bits/sec, taking into account the random seed,
> I'll be convinced :-)

OpenSSL's implementation of SHA-1 is as fast as its implementation of
MD4, and both are much faster than librsync's built-in MD4. For MD4, an
efficient second-preimage attack is known, whereas for SHA1, even a
collision has not been demonstrated yet (the best attack presently known
takes ~2^63 work). Is this sufficient evidence?

> In any case, the first thing that will be tackled is changing to use the
> libmd/openssl API for hashes, which will make switching what hash we
> want to use painless... a configure option?

Makes sense, and while at it, please consider setting the default block
hash to SHA-1.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sekar Vembu | 20 Mar 2006 07:25
Favicon

bug 1110812 - 4Gigbug.patch does not work in Windows

Hi,
This is regarding the 4Gigbug.patch for the bug request id: 1110812. 
This patch works well in Linux for file sizes more than 4GB. But the 
large file problem (greater than 4GB) still exists in Windows. I think 
here is what is happening.

The fseek  in rs_file_copy_cb() method of buf.c still throws an error 
when the seek is beyond 4GB. We tried changing the fseek to _lseeki64 
and typedefinition of rs_long_t to __int64. But the problem is still 
there. We do not know how to get fseek to work for large files (>4GB) in 
Windows.

The error thrown in librsync while applying the delta is :

librsync: ERROR: (librsync) seek failed: Invalid argument
librsync: ERROR: (librsync) patch job failed: IO error

Can someone help with this.

Thanks
Sekar.

-------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
Sekar Vembu | 20 Mar 2006 13:48
Favicon

[Fwd: bug 1110812 - 4Gigbug.patch does not work in Windows]

Hi,
Subsequent to my original email, I think we have fixed the large file 
problem in Windows too. We have made minor modifications to three files. 
We have tested this and it seems to work for us. I am attaching the 
three files with this email.
1. buf.c
2. librsync.h
3.PcBuild\librsync-config.h

The following are the cvs-diff for those three files. Hope some expert 
will review this and check this in to the librsync CVS. If there is a 
problem with these changes please let me know.

cvs diff buf.c
Index: buf.c
===================================================================
RCS file: /cvsroot/librsync/librsync/buf.c,v
retrieving revision 1.22
diff -r1.22 buf.c
209c209,215
<     if (fseek(f, pos, SEEK_SET)) {
---
 >    
 >
 >     #if WIN32
 >         if (_fseeki64(f, (__int64)pos, SEEK_SET) < 0 ) {
 >     #else
 >         if (fseek(f, pos, SEEK_SET)) {
 >     #endif
(Continue reading)

Permalink | Reply | 4 comments |
headers
Donovan Baarda | 20 Mar 2006 14:43
Picon
Picon
Gravatar

Re: [Fwd: bug 1110812 - 4Gigbug.patch does not work in Windows]

On Mon, 2006-03-20 at 18:18 +0530, Sekar Vembu wrote:
> Hi,
> Subsequent to my original email, I think we have fixed the large file 
> problem in Windows too. We have made minor modifications to three files. 
> We have tested this and it seems to work for us. I am attaching the 
> three files with this email.
> 1. buf.c
> 2. librsync.h
> 3.PcBuild\librsync-config.h
> 
> The following are the cvs-diff for those three files. Hope some expert 
> will review this and check this in to the librsync CVS. If there is a 
> problem with these changes please let me know.

Please submit patches at the SF patch tracker...

Also, looking at this, I have a feeling this is compiler dependant,
rather than just WIN32 dependent. I suspect this stuff should be handled
by configure, rather than peppering the code with more #if WIN32 stuff.
Note that PCBuild/librsync-config.h should be auto-generated by running
configure with a MSC system.

In any case, thanks for this... if no one else gets around to it before
me, I'll look into it and see what the best approach for this is...

--

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

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 3 comments |
headers
Sekar Vembu | 20 Mar 2006 14:48
Favicon

Re: [Fwd: bug 1110812 - 4Gigbug.patch does not work in Windows]

Sorry about not using the SF patch tracker. We will learn the right way 
to send patches in the future. Hopefully these fixes are useful and you 
can incorporate it with the right approach in the librsync source code.

Thanks
Sekar

Donovan Baarda wrote:

>On Mon, 2006-03-20 at 18:18 +0530, Sekar Vembu wrote:
>  
>
>>Hi,
>>Subsequent to my original email, I think we have fixed the large file 
>>problem in Windows too. We have made minor modifications to three files. 
>>We have tested this and it seems to work for us. I am attaching the 
>>three files with this email.
>>1. buf.c
>>2. librsync.h
>>3.PcBuild\librsync-config.h
>>
>>The following are the cvs-diff for those three files. Hope some expert 
>>will review this and check this in to the librsync CVS. If there is a 
>>problem with these changes please let me know.
>>    
>>
>
>Please submit patches at the SF patch tracker...
>
>Also, looking at this, I have a feeling this is compiler dependant,
(Continue reading)

Permalink | Reply | 2 comments |
headers
Donovan Baarda | 20 Mar 2006 14:59
Picon
Picon
Gravatar

Re: [Fwd: bug 1110812 - 4Gigbug.patch does not work in Windows]

On Mon, 2006-03-20 at 19:18 +0530, Sekar Vembu wrote:
> Sorry about not using the SF patch tracker. We will learn the right way 
> to send patches in the future. Hopefully these fixes are useful and you 
> can incorporate it with the right approach in the librsync source code.

Thanks... also, it is worth subscribing to the librsync-dev list on
SF... it means I don't have to keep approving your non-subscriber posts.

These fixes are definitely useful and will go in... the only thing yet
to be determined is how and when :-)

> Thanks
> Sekar
> 
> Donovan Baarda wrote:
> 
> >On Mon, 2006-03-20 at 18:18 +0530, Sekar Vembu wrote:
> >  
> >
> >>Hi,
> >>Subsequent to my original email, I think we have fixed the large file 
> >>problem in Windows too. We have made minor modifications to three files. 
> >>We have tested this and it seems to work for us. I am attaching the 
> >>three files with this email.
> >>1. buf.c
> >>2. librsync.h
> >>3.PcBuild\librsync-config.h
> >>
> >>The following are the cvs-diff for those three files. Hope some expert 
> >>will review this and check this in to the librsync CVS. If there is a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane