G'day,
From: Wayne Davison [EMAIL PROTECTED]
On Thu, Apr 08, 2004 at 03:50:48PM +1000, Donovan Baarda wrote:
I think I've just realised what you were getting at; if the
checksum_seed is based on something like the whole file md4sum, it
becomes repeatable, but unpredictable.
Not so. Copy
Hi,
On 2004/04/05 07:21, Donovan Baarda wrote:
[snip]
there are four ways crafted blocks can be use;
1) two crafted blocks in the original file
2) two crafted blocks in the target file
3) a crafted pair of target and original files with matching
block(s)
4) a block in the target
G'day,
From: Eran Tromer [EMAIL PROTECTED]
[...]
librsync needs a whole file checksum. Without it, it silently fails for
case 1), 3), and 4).
librsync could benefit from a random checksum_seed. It would need to be
included in the signature. Without it librsync is vulnerable to cases 1)
On 2004/04/08 08:50, Donovan Baarda wrote:
In some cases you might prefer to actually store an signed signature
using something like GPG.
I think librsync should act as a black box that guarantees file
integrity (which, apparently, requires a whole file checksum). If
someone wants to add
G'day again,
From: Eran Tromer [EMAIL PROTECTED]
[...]
if the
checksum_seed is based on something like the whole file md4sum, it
becomes repeatable, but unpredictable. You can't manipulate individual
blocks without it affecting every other blocksum, but the signature for
the same file
Ahoy,
On 2004/04/08 14:16, Donovan Baarda wrote:
Nice indeed, but the cost is enormous: you'll have to read the file
twice. When syncing a mostly-unchanged file that's larger than the disk
cache, that means doubling the runtime (and disk load) on the receiver's
side. Also, it means 'rdiff
On Thu, Apr 08, 2004 at 03:50:48PM +1000, Donovan Baarda wrote:
I think I've just realised what you were getting at; if the
checksum_seed is based on something like the whole file md4sum, it
becomes repeatable, but unpredictable.
Not so. Copy the file once, and you'd get all the data you'd
On Thu, 2004-04-08 at 12:36, Martin Pool wrote:
On 5 Apr 2004, Donovan Baarda [EMAIL PROTECTED] wrote:
librsync needs a whole file checksum. Without it, it silently fails for
case 1), 3), and 4).
Yes, a whole-file checksum should be used with it. Presumably
something stronger than md4
G'day again,
Just revisiting an old thread after some more thought. Eran and I were
discussing the vulerability of librsync and rsync to deliberate attempts
to craft blocks with matching signatures but different content. It turns
out it's disturbingly easy. Here's a bit of context;
From: Donovan
Hi,
On 2004/03/17 00:07, Donovan Baarda wrote:
Quoth RFC 1950:
That 65521 is prime is important to avoid a possible large class of
two-byte errors that leave the check unchanged.
Not much of a difference in adversarial setting, though.
And not much of a difference I think for rsync in
Donovan Baarda wrote:
On Tue, 2004-03-16 at 10:44, Eran Tromer wrote:
with an 8-byte hash that means you tested approximately 2^64/2 crafted
fletcher busting blocks to find a collision, yeah?
[snip]
I thought that without using some sort of known vulnerability the
formula would be;
avg
G'day,
From: Eran Tromer [EMAIL PROTECTED]
Donovan Baarda wrote:
[...]
I thought that without using some sort of known vulnerability the
formula would be;
avg number of random attempts = number of possible sum values / 2
Uhm, no -- just 2^(64/2)=2^32 random blocks, by the Birthday
Hi,
On 2004/03/15 03:49, Donovan Baarda wrote:
Note that, above, block hash collisions are very easy to find if you
know checksum_seed. The rolling Fletcher checksum1 is trivially
defeated. To defeat the k-bit truncated MD4 checksum2, just keep
generate random blocks having the same checksum1
On Tue, 2004-03-16 at 10:44, Eran Tromer wrote:
Hi,
On 2004/03/15 03:49, Donovan Baarda wrote:
[...]
Just to be sure, I wrote a quickdirty collision search code for the
rsync and librsync hashes. I used a generic collision-finding algorithm
(namely Gabriel Nivasch's multistack variant of
On Wed, 2004-03-10 at 16:43, Eran Tromer wrote:
[...]
Note that, above, block hash collisions are very easy to find if you
know checksum_seed. The rolling Fletcher checksum1 is trivially
defeated. To defeat the k-bit truncated MD4 checksum2, just keep
generate random blocks having the same
15 matches
Mail list logo
