On Fri, Sep 20, 2013 at 04:17:51PM +0200, Janne Johansson wrote:
> 2013/9/20
>
> > Janne Johansson wrote:
> >
> > > In practical terms, if I rsync a file from X to Y, and rsync says it is
> > > complete, how to verify the 4G files actually are equal?
> > > Given that rsync only knows that hash(A
On Sep 24 08:07:30, hru...@gmail.com wrote:
> On Fri, 20 Sep 2013, Johan Mellberg wrote:
>
> > Your error in thinking is that if we have an extremely large set of strings,
> > a very large set is mapped to each hash value. Therefore you reason that a
> > collision is very likely. But if you are co
On Fri, 20 Sep 2013, Johan Mellberg wrote:
> Your error in thinking is that if we have an extremely large set of strings,
> a very large set is mapped to each hash value. Therefore you reason that a
> collision is very likely. But if you are comparing two specific strings, the
> likelihood of them
I didn't seem to get an answer here.
How would I know that the 4G wav-file I sent from one box to another is
100% identical?
If we assume (and I think that is what you seem to claim) that we can't
blindly trust hashing, but we will assume that no cosmic rays nor
hard-drive bit failures can affect
On Fri, September 20, 2013 5:51 am, hru...@gmail.com wrote:
> Janne Johansson wrote:
>
>> In practical terms, if I rsync a file from X to Y, and rsync says it is
>> complete, how to verify the 4G files actually are equal?
>> Given that rsync only knows that hash(A) was equal to hash(B) at the
>> e
Rodrigo,
> 20 sep 2013 kl. 14:51 skrev hru...@gmail.com:
>
> and developers of OpenBSD have here a strange standpoint that they
> defend without sound argumentation, including asking the one that
> expresses the critics that he goes away.
But have you understood why?
You claim that what most pe
On Fri, 20 Sep 2013, Janne Johansson wrote:
> 2013/9/20
>
> > Janne Johansson wrote:
> >
> > > In practical terms, if I rsync a file from X to Y, and rsync says it is
> > > complete, how to verify the 4G files actually are equal?
> > > Given that rsync only knows that hash(A) was equal to hash(
2013/9/20
> Janne Johansson wrote:
>
> > In practical terms, if I rsync a file from X to Y, and rsync says it is
> > complete, how to verify the 4G files actually are equal?
> > Given that rsync only knows that hash(A) was equal to hash(B) at the end,
> > what do you propose to use for verificat
On Fri, Sep 20, 2013 at 03:31:18PM +0200, Paul de Weerd wrote:
> On Fri, Sep 20, 2013 at 02:49:27PM +0200, Raimo Niskanen wrote:
> | On Fri, Sep 20, 2013 at 11:47:06AM +, hru...@gmail.com wrote:
> | > Andreas Gunnarsson wrote:
> | >
> | > > On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gma
> 20 sep 2013 kl. 14:51 skrev hru...@gmail.com:
>
> and developers of OpenBSD have here a strange standpoint that they
> defend without sound argumentation, including asking the one that
> expresses the critics that he goes away.
But have you understood why?
You claim that what most people here
On Fri, Sep 20, 2013 at 02:49:27PM +0200, Raimo Niskanen wrote:
| On Fri, Sep 20, 2013 at 11:47:06AM +, hru...@gmail.com wrote:
| > Andreas Gunnarsson wrote:
| >
| > > On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gmail.com wrote:
| > > > Raimo, if people believe that hash(A)=hash(B) impli
Janne Johansson wrote:
> In practical terms, if I rsync a file from X to Y, and rsync says it is
> complete, how to verify the 4G files actually are equal?
> Given that rsync only knows that hash(A) was equal to hash(B) at the end,
> what do you propose to use for verification?
In practical term
On Fri, Sep 20, 2013 at 11:47:06AM +, hru...@gmail.com wrote:
> Andreas Gunnarsson wrote:
>
> > On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gmail.com wrote:
> > > Raimo, if people believe that hash(A)=hash(B) implies A=B, so strong
> > > believe, that they use it in their programs,
> >
>
> > Raimo, if people believe that hash(A)=hash(B) implies A=B, so strong
> > > believe, that they use it in their programs,
> >
> > It's a matter of engineering. Usually that is good enough.
> >
> > If you don't think it's good enough then you should probably also worry
> > about how often strcmp(
Andreas Gunnarsson wrote:
> On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gmail.com wrote:
> > Raimo, if people believe that hash(A)=hash(B) implies A=B, so strong
> > believe, that they use it in their programs,
>
> It's a matter of engineering. Usually that is good enough.
>
> If you don't t
That was very good articles. Thank you for enlightening me.
On Thu, Sep 19, 2013 at 01:49:05PM -0500, Matthew Weigel wrote:
> On 09/19/2013 08:46 AM, hru...@gmail.com wrote:
>
> >From time to time I think I should follow Kenneth Westerbacks
> >recomendation
> >and go to a math-for-idiots list, f
Mihai Popescu wrote:
> > "An Analysis of Data Corruption in the Storage Stack"
> > http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
>
> They claim the paper is based on 1.53 million disk drives.
> It is interesting they were able to access such a number.
The paper is based on NetApp data.
-
On Thu, Sep 19, 2013 at 11:49:56PM +0300, Mihai Popescu wrote:
| > Since I mentioned the likelihood of a non-recoverable disk error,
| > here's a terrific paper that should make everbody sleep very poorly:
| >
| > "An Analysis of Data Corruption in the Storage Stack"
| > http://www.cs.toronto.edu/~
> Since I mentioned the likelihood of a non-recoverable disk error,
> here's a terrific paper that should make everbody sleep very poorly:
>
> "An Analysis of Data Corruption in the Storage Stack"
> http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
They claim the paper is based on 1.53 million d
Since I mentioned the likelihood of a non-recoverable disk error,
here's a terrific paper that should make everbody sleep very poorly:
"An Analysis of Data Corruption in the Storage Stack"
http://www.cs.toronto.edu/~bianca/papers/fast08.pdf
--
Christian "naddy" Weisgerber
On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gmail.com wrote:
> Raimo, if people believe that hash(A)=hash(B) implies A=B, so strong
> believe, that they use it in their programs,
It's a matter of engineering. Usually that is good enough.
If you don't think it's good enough then you should pr
On 09/19/2013 08:46 AM, hru...@gmail.com wrote:
From time to time I think I should follow Kenneth Westerbacks
recomendation
and go to a math-for-idiots list, for example to Usenet Group
"sci.math",
and then make a link to this thread in gmane: they will sure admire
Marc
Espies wisdom and his
Raimo Niskanen wrote:
> Rodrigo,
>
> was there anything wrong with my answer below (and others equal),
> apart from it not being the one you wanted, since you keep repeating
> the same question over and over again?
>
> Do you have a better answer? Please share it for us to check.
Raimo, if peop
Rodrigo,
was there anything wrong with my answer below (and others equal),
apart from it not being the one you wanted, since you keep repeating
the same question over and over again?
Do you have a better answer? Please share it for us to check.
On Tue, Sep 17, 2013 at 03:58:34PM +0200, Raimo
I want to give a hint for those working till now in the problem of
estimating the probability of A=B under the condition of hash(A)=hash(B).
Just suppose that hash is any function from a set X to Y, first suppose
that X is finite (but very big), and that the probability to pick any
element is the
On Thu, 19 Sep 2013 08:01:13 +0200, Janne Johansson wrote:
>2013/9/19
>
>> Alexander Hall wrote:
>> > Marc already anwered all your questions. Let me quote it.
>> >
>> > > Fuck off
>>
>> The most brilliant answers of the experts:
>>
>
>An old quote which fits nicely here:
>
>A book is a mirror:
2013/9/19
> Alexander Hall wrote:
> > Marc already anwered all your questions. Let me quote it.
> >
> > > Fuck off
>
> The most brilliant answers of the experts:
>
An old quote which fits nicely here:
A book is a mirror: if an ape looks into it an apostle is hardly likely to
look out. We have
hru...@gmail.com writes:
> Alexander Hall wrote:
>
>> Marc already anwered all your questions. Let me quote it.
>>
>> > Fuck off
>
> The most brilliant answers of the experts:
[...]
Those people, that you qualify as experts, have spent hours reading and
answering your mails. I bet you're prett
@openbsd.org
Subject: Re: cvsync, rsync
On Tue, Sep 17, 2013 at 04:16:47PM +, hru...@gmail.com wrote:
> Intentionally I left the problem generic. Is the probability near to 1?
YES it is near to 1.
Your way to phrase mathematical problems is BOGUS. You can't do probability
without formulati
On Tue, 17 Sep 2013, Raimo Niskanen wrote:
> Suppose you are limited to length 1 strings of [a-z], then you have
> 29 possible strings.
>
> Still. If you select one of those strings and calculates its SHA-1
> hash value. When you try any of the other 28 strings (or any other
> string of any lengh
Marc already anwered all your questions. Let me quote it.
Fuck off
/Alexander
On 09/18/13 23:59, hru...@gmail.com wrote:
What was the probability?
Rodrigo.
Eric Furman wrote:
Troll, the question has been answered.
You are an entertaining troll, though.
It is highly amusing seeing someo
What was the probability?
Rodrigo.
Eric Furman wrote:
> Troll, the question has been answered.
> You are an entertaining troll, though.
> It is highly amusing seeing someone make themselves look so silly.
>
> On Tue, Sep 17, 2013, at 11:28 AM, hru...@gmail.com wrote:
> > Marc Espie wrote:
> >
On Wed, Sep 18, 2013 at 09:25:55PM +, hru...@gmail.com wrote:
> Henning Brauer wrote:
>
> > * hru...@gmail.com [2013-09-16 21:33]:
> > > It confirms that it supposes: A=B if hash(A)=hash(B).
> >
> > which is fine even with a relatively poor hash like md5 when the size
> > is also checked.
>
Henning Brauer wrote:
> * hru...@gmail.com [2013-09-16 21:33]:
> > It confirms that it supposes: A=B if hash(A)=hash(B).
>
> which is fine even with a relatively poor hash like md5 when the size
> is also checked.
A=B because parts of the file in the server coincide with parts of the
file in th
* hru...@gmail.com [2013-09-16 21:33]:
> It confirms that it supposes: A=B if hash(A)=hash(B).
which is fine even with a relatively poor hash like md5 when the size
is also checked.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secur
On Tue, Sep 17, 2013 at 06:18:48PM +, hru...@gmail.com wrote:
> Kenneth R Westerback wrote:
>
> > And your endless meanderings around the pointless questions you pose
> > are not welcome on the list. They certainly have NOTHING to do with
> > OpenBSD.
>
> What you say in the last sentence is
On Tue, Sep 17, 2013 at 03:22:16PM +, hru...@gmail.com wrote:
> I wrote to the list. If you have something to say about the thema,
> then please to the list. Your impolite mails are not welcome in
> my mailbox.
>
> Rodrigo.
And your endless meanderings around the pointless questions you pose
> But in general, in case of foul play, you have ways ways more
> to worry about than whether your hash is going to match!
>
> (and the attacks we know about for md5 and sha1 are of the "choose preimage
> variety", so it's for files A and B that *the attacker* can choose, not your
> own A file, a
Kenneth R Westerback wrote:
> And your endless meanderings around the pointless questions you pose
> are not welcome on the list. They certainly have NOTHING to do with
> OpenBSD.
What you say in the last sentence is exactly what I hope. One
of my questions was:
"This is a conjecture. Do you ha
INSUFFICIENT DATA
-Original Message-
From: owner-m...@openbsd.org [mailto:owner-m...@openbsd.org] On Behalf Of
hru...@gmail.com
Sent: Tuesday, September 17, 2013 10:28 AM
To: misc@openbsd.org
Subject: Re: cvsync, rsync
Marc Espie wrote:
> > You have strings A and B, and you kno
On Tue, Sep 17, 2013 at 04:16:47PM +, hru...@gmail.com wrote:
> Intentionally I left the problem generic. Is the probability near to 1?
YES it is near to 1.
Your way to phrase mathematical problems is BOGUS. You can't do probability
without formulating a set of complete hypothesis.
Your way
Marc Espie wrote:
> > You have strings A and B, and you know only that hash(A)=hash(B): what
> > is the probability that A=B? 2^-160?
>
> No, that's never the problem.
>
> You have a *given* string A, and another string B.
O.K. You have string A in the client with hash(A)=n. You find string
B
lf Of
> hru...@gmail.com
> Sent: Tuesday, September 17, 2013 10:28 AM
> To: misc@openbsd.org
> Subject: Re: cvsync, rsync
>
> Marc Espie wrote:
>
> > > You have strings A and B, and you know only that hash(A)=hash(B): what
> > > is the probability that
On Tue, Sep 17, 2013 at 03:28:11PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > > You have strings A and B, and you know only that hash(A)=hash(B): what
> > > is the probability that A=B? 2^-160?
> >
> > No, that's never the problem.
> >
> > You have a *given* string A, and another
I wrote to the list. If you have something to say about the thema,
then please to the list. Your impolite mails are not welcome in
my mailbox.
Rodrigo.
Jan Stary wrote:
> On Sep 17 13:21:04, hru...@gmail.com wrote:
> > Raimo Niskanen wrote:
> >
> > > When you have two different real world co
On Tue, Sep 17, 2013 at 01:27:06PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote:
> > > In the case of rsync the hash is applied to strings of a fixed lenth.
> > > In this case the input is finite and we can argue with ca
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote:
> Raimo Niskanen wrote:
>
> > When you have two different real world contents the collision probability
> > is just that; 2^-160 for SHA-1. It is when you deliberately craft a
> > second content to match a known hash value there ma
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote:
> Raimo Niskanen wrote:
>
> > When you have two different real world contents the collision probability
> > is just that; 2^-160 for SHA-1. It is when you deliberately craft a
> > second content to match a known hash value there ma
Marc Espie wrote:
> On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote:
> > In the case of rsync the hash is applied to strings of a fixed lenth.
> > In this case the input is finite and we can argue with cardinality.
> > Just imagine the set finite strings mapped to a single elemen
Raimo Niskanen wrote:
> When you have two different real world contents the collision probability
> is just that; 2^-160 for SHA-1. It is when you deliberately craft a
> second content to match a known hash value there may be weaknesses
> in cryptographic hash functions, but this is not what rsyn
> Alexander Hall wrote:
>
>> Leaving the internals of rsync aside (of which I assume much but *know*
>> little), if I consider two 4TB blobs to be equal just because they have
>> the same SHA1 hash, I can easily see myself ending up in one of these
>> conditions (but not both):
>
> This was git, n
On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote:
> In the case of rsync the hash is applied to strings of a fixed lenth.
> In this case the input is finite and we can argue with cardinality.
> Just imagine the set finite strings mapped to a single element in the
> range. If all the
On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
> > > Marc Espie wrote:
> > >
> > > > > >From a checksum I expect two things: (1) the pre-images of elements
> > > > > in the range have
Marc Espie wrote:
> On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
> > Marc Espie wrote:
> >
> > > > >From a checksum I expect two things: (1) the pre-images of elements
> > > > in the range have all similar sizes,
> > > Why ? This makes no sense, and is in contradiction wi
Alexander Hall wrote:
> Leaving the internals of rsync aside (of which I assume much but *know*
> little), if I consider two 4TB blobs to be equal just because they have
> the same SHA1 hash, I can easily see myself ending up in one of these
> conditions (but not both):
This was git, not rsyn
On 09/16/13 17:36, Raimo Niskanen wrote:
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
Raimo Niskanen wrote:
A resembling application is the Git version control system that is
based on the assumption that all content blobs can be uniquely
decribed by their 128-bit SHA1
Marc Espie wrote:
> > And now we are back to my starting poit. The checksum is not used
> > in rsync as a pure checksum to find accidental errors. That was my
> > critic.
>
> No, it is. Really. Read the papers. Do your homework, check the maths.
I have read this:
http://rsync.samba.org/tech_
On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > > >From a checksum I expect two things: (1) the pre-images of elements
> > > in the range have all similar sizes,
> > Why ? This makes no sense, and is in contradiction with (2).
>
> I must correct my p
Marc Espie wrote:
> > >From a checksum I expect two things: (1) the pre-images of elements
> > in the range have all similar sizes,
> Why ? This makes no sense, and is in contradiction with (2).
I must correct my previous mail. The Domain is numerable, to speak
about cardinality as size do not
Raimo Niskanen wrote:
> A resembling application is the Git version control system that is
> based on the assumption that all content blobs can be uniquely
> decribed by their 128-bit SHA1 hash value. If two blobs have
> the same hash value they are assumed to be identical.
The developers of rsy
On Mon, Sep 16, 2013 at 05:52:27PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > A little knowledge is a dangerous thing.
> >
> > "weakness" in a cryptographic setting doesn't mean *anything* if
> > you're using it as a pure checksum to find out accidental errors.
>
> And now we are
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
> Raimo Niskanen wrote:
>
> > A resembling application is the Git version control system that is
> > based on the assumption that all content blobs can be uniquely
> > decribed by their 128-bit SHA1 hash value.
>
On Mon, Sep 16, 2013 at 05:46:26PM +0200, Raimo Niskanen wrote:
> On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
> > Raimo Niskanen wrote:
> >
> > > A resembling application is the Git version control system that is
> > > based on the assumption that all content blobs can b
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
> Raimo Niskanen wrote:
>
> > A resembling application is the Git version control system that is
> > based on the assumption that all content blobs can be uniquely
> > decribed by their 128-bit SHA1 hash value.
>
Raimo Niskanen wrote:
> A resembling application is the Git version control system that is
> based on the assumption that all content blobs can be uniquely
> decribed by their 128-bit SHA1 hash value.
^
... 160-bit SHA1 hash...
--
Christian "naddy" Weisgerber
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > On Sat, Sep 14, 2013 at 03:09:48PM +, hru...@gmail.com wrote:
> >
> > > A completely other thing is to conclude that two *arbitrary* pieces of
> > > data are the same only because they have the same ha
Marc Espie wrote:
> I consider 1/2^128 to be *vanishingly small*.
Christian Weisgerber mentions that a relative small range of
the hash function would be a problem, but a big range is not
enough: the whole depends on the hash function itself. But this would
be a big discussion: in some context
wrote:
> Does rsync suppose that a part of a file in the server is equal to
> a part of a file in the client, if a hash value of these parts are
> equal?
Yes.
> Does cvsync do the same?
(Embarrassingly, I don't actually remember how cvsync works in
detail.)
> Is this reliable?
In practice, y
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
> Is there an alternative for downloading the repository without the
> conjecture?
Use ftp.
That way, you will get rid of those pesky 128 bits checksum, and only rely
on your TCP/IP to be reliable. I'm pretty sure the built-in che
This just in, all the data in the world successfully moved with rsync just
a coincidence.
On Sat, Sep 14, 2013 at 11:34 AM, Marc Espie wrote:
> On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
> > Marc Espie wrote:
> >
> > > On Sat, Sep 14, 2013 at 03:09:48PM +, hru...@gma
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
> Marc Espie wrote:
>
> > On Sat, Sep 14, 2013 at 03:09:48PM +, hru...@gmail.com wrote:
> >
> > > A completely other thing is to conclude that two *arbitrary* pieces of
> > > data are the same only because they have the same ha
Marc Espie wrote:
> On Sat, Sep 14, 2013 at 03:09:48PM +, hru...@gmail.com wrote:
>
> > A completely other thing is to conclude that two *arbitrary* pieces of
> > data are the same only because they have the same hash. Arbitrary
> > means here that the one was not a copy of the other. And th
On Sat, Sep 14, 2013 at 03:09:48PM +, hru...@gmail.com wrote:
> A completely other thing is to conclude that two *arbitrary* pieces of
> data are the same only because they have the same hash. Arbitrary
> means here that the one was not a copy of the other. And this is what
> rsync seems to do
On Sat, Sep 14, 2013 at 01:59:50PM +, hru...@gmail.com wrote:
> Dear Sirs!
>
> I have a question, perhaps a little of-topic, but it arose as I
> read about cvsync in openbsd web page. And OpenBsd people sure know
> a lot about cryptography :)
>
> Does rsync suppose that a part of a file in th
Kenneth R Westerback wrote:
> People use cvsync or rsync to create/maintain a local copy or copies
[...]
> Not sure what your 'reliable' metrics are, but works for me.
My question was not about what people do or if it works (till now)
for you. It was about the algorithm.
Is the algorithm corr
75 matches
Mail list logo
