On Tue, May 18, 2004 at 10:21:04PM -0700, Craig Barratt wrote:
> Probably the best solution is to add a flag argument to sum_init(void)
> to request whether to add checksum_seed or not.
How about this similar idea: change sum_init() to take a seed value as
an arg. Then, call it with sum_
u specify --checksum-seed=N on the client
when connecting to an rsyncd server, the authentication response is
based on an MD4 digest computed by calling sum_init(), sum_update() and
sum_end(). sum_init() adds checksum_seed to the digest data. The
problem at this point is the args have not be
Wayne Davison writes:
> On Sat, May 15, 2004 at 02:25:11PM -0700, Craig Barratt wrote:
> > Any feedback on this patch and the possibility of getting it
> > into CVS or the patches directory?
>
> The file checksum-seed.diff was put into the patches dir on the 2nd of
> May. Strangely, I don't seem
On Sat, May 15, 2004 at 02:25:11PM -0700, Craig Barratt wrote:
> Any feedback on this patch and the possibility of getting it
> into CVS or the patches directory?
The file checksum-seed.diff was put into the patches dir on the 2nd of
May. Strangely, I don't seem to have sent any email indicating
Subject: Re: setting checksum_seed
jw schultz writes:
> > > There was some talk last year about adding a --fixed-checksum-seed
> > > option, but no consensus was reached. It shouldn't hurt to make the
> > > seed value constant for certain applications, though, s
ree to proceed in that direction for what you're doing for your client.
> > >
> > > FYI, I just checked in some changes to the checksum_seed code that will
> > > make it easier to have other options (besides the batch ones) specify
> > > that a constant see
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
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
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
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 aff
tead of computing their own.
> 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 is a
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
> >
> 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)
> and 3).
[snip]
> rsync shoul
use a whole file
md4sum though.
> > 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)
> > and 3).
>
> Random with respect to what? I think it would be nice if repeat
aliciously crafted file is
corrupted? In rsync this can be used as a performance degradation
attack. However, librsync by default uses a psedo-random checksum_seed,
that makes such an attack nearly impossible (however... the original
discussion started around using a fixed checksum_seed in "batch mode&q
andom data because the
distribution of s1 is highly concentrated around blocksize/2 (for large
blocks the wrap-arounds tend to smoothen the distribution).
You can build the random lookup table by applying a PRNG to the
(random!) checksum_seed, so that there's no further increase in delta
size
G'day,
cc'ing to the librsync-dev list as this is pretty relevant there.
On Thu, 2004-03-18 at 04:41, Eran Tromer wrote:
> Hi,
[...]
> >>>Have you looked at the librsync rollsum.c implementation in CVS? It
> >>>replaced rs_calc_weak_sum and should be a fair bit faster.
>
> Here are run times for
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
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 B
ly on
randomness of preceding blocks (which wouldn't be a good idea anyway).
>>In adversarial setting the Fletcher checksum is worthless. So to obtain
>>the intended 2^-10 failure probability, rsync should increase its strong
>>checksum by 4 bytes.
>>
>>That's
l Nivasch's multistack variant of the generalized Rho
> method) to search for a truncated MD4 collision among the blocks whose
> Fletcher sum is zero. It took 13ms to find a collision for the default
> parameters of rsync version<2.6.0, with either checksum_seed=0
> (disabled) or chec
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 rando
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 hav
Hi,
The following lines in compat.c are rather imprudent:
if (read_batch || write_batch)
checksum_seed = 32761;
else
checksum_seed = time(NULL);
write_int(f_out,checksum_seed);
Setting checksum_seed to a constant in batch mode means block collisions
are reproducible
sync/options.c rsync-fixedcsum/options.c
--- rsync/options.c Tue Feb 10 20:30:41 2004
+++ rsync-fixedcsum/options.c Mon Feb 16 12:32:23 2004
@@ -89,6 +89,7 @@
int modify_window = 0;
int blocking_io = -1;
int checksum_seed = 0;
+int fixed_csumseed = 0;
unsigned int block_size = 0;
@@
hed. It shouldn't hurt to make the
> > seed value constant for certain applications, though, so you can feel
> > free to proceed in that direction for what you're doing for your client.
> >
> > FYI, I just checked in some changes to the checksum_seed code that will
;re doing for your client.
>
> FYI, I just checked in some changes to the checksum_seed code that will
> make it easier to have other options (besides the batch ones) specify
> that a constant seed value is needed.
I would really like a --fixed-csumseed option become a standard
feature in
what you're doing for your client.
FYI, I just checked in some changes to the checksum_seed code that will
make it easier to have other options (besides the batch ones) specify
that a constant seed value is needed.
..wayne..
--
To unsubscribe or change options: http://lists.samba.org/mailm
What is the point to checksum_seed? When reading/writing batch, it is
initialized to a constant value, otherwise it is initialized to
time(NULL). It certainly has no useful cryptographic value :)
I got the go-ahead from the client on my --link-by-hash proposal, and the
seed is making the hash
29 matches
Mail list logo
