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
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
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 comparing
On Fri, Sep 20, 2013 at 04:17:51PM +0200, Janne Johansson wrote:
2013/9/20 hru...@gmail.com
Janne Johansson icepic...@gmail.com 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
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, for
Andreas Gunnarsson o-m...@zzlevo.net 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
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(a, b) returns
On Fri, Sep 20, 2013 at 11:47:06AM +, hru...@gmail.com wrote:
Andreas Gunnarsson o-m...@zzlevo.net 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
Janne Johansson icepic...@gmail.com 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?
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 o-m...@zzlevo.net wrote:
|
| On Thu, Sep 19, 2013 at 01:46:20PM +, hru...@gmail.com wrote:
|Raimo, if people believe that
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 know
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 o-m...@zzlevo.net wrote:
|
| On Thu, Sep 19, 2013 at 01:46:20PM +,
2013/9/20 hru...@gmail.com
Janne Johansson icepic...@gmail.com 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
On Fri, 20 Sep 2013, Janne Johansson wrote:
2013/9/20 hru...@gmail.com
Janne Johansson icepic...@gmail.com 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
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 people
On Fri, September 20, 2013 5:51 am, hru...@gmail.com wrote:
Janne Johansson icepic...@gmail.com 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)
2013/9/19 hru...@gmail.com
Alexander Hall alexan...@beard.se 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
On Thu, 19 Sep 2013 08:01:13 +0200, Janne Johansson wrote:
2013/9/19 hru...@gmail.com
Alexander Hall alexan...@beard.se 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
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
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
Raimo Niskanen raimo+open...@erix.ericsson.se 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
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
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
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
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 disk
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
|
Mihai Popescu mih...@gmail.com 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
* hru...@gmail.com 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,
Henning Brauer lists-open...@bsws.de wrote:
* hru...@gmail.com 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
On Wed, Sep 18, 2013 at 09:25:55PM +, hru...@gmail.com wrote:
Henning Brauer lists-open...@bsws.de wrote:
* hru...@gmail.com 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
What was the probability?
Rodrigo.
Eric Furman ericfur...@fastmail.net 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
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 ericfur...@fastmail.net wrote:
Troll, the question has been answered.
You are an entertaining troll, though.
It is
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 lenght)
...@servasoftware.com, misc@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
hru...@gmail.com writes:
Alexander Hall alexan...@beard.se 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
Alexander Hall alexan...@beard.se 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
Marc Espie es...@nerim.net wrote:
On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
On Tue, Sep 17, 2013 at 07:23:07AM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net wrote:
On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net wrote:
From a checksum I expect two things: (1) the pre-images of elements
in the
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 these
Alexander Hall alexan...@beard.se 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
Raimo Niskanen raimo+open...@erix.ericsson.se 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
Marc Espie es...@nerim.net 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
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se 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
On Tue, Sep 17, 2013 at 01:21:04PM +, hru...@gmail.com wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se 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
On Tue, Sep 17, 2013 at 01:27:06PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
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 h...@stare.cz wrote:
On Sep 17 13:21:04, hru...@gmail.com wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se wrote:
When
On Tue, Sep 17, 2013 at 03:28:11PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
] On Behalf Of
hru...@gmail.com
Sent: Tuesday, September 17, 2013 10:28 AM
To: misc@openbsd.org
Subject: Re: cvsync, rsync
Marc Espie es...@nerim.net 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
Marc Espie es...@nerim.net 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
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
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 es...@nerim.net wrote:
You have strings A and B
Kenneth R Westerback kwesterb...@rogers.com 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
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, and a B
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
are
On Tue, Sep 17, 2013 at 06:18:48PM +, hru...@gmail.com wrote:
Kenneth R Westerback kwesterb...@rogers.com 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
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
Raimo Niskanen raimo+open...@erix.ericsson.se 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...
--
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se 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
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 raimo+open...@erix.ericsson.se wrote:
A resembling application is the Git version control system that is
based on the assumption that all
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se 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
On Mon, Sep 16, 2013 at 05:52:27PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
Raimo Niskanen raimo+open...@erix.ericsson.se 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
Marc Espie es...@nerim.net 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
On Mon, Sep 16, 2013 at 08:16:50PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
Marc Espie es...@nerim.net 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:
On 09/16/13 17:36, Raimo Niskanen wrote:
On Mon, Sep 16, 2013 at 02:25:58PM +, Christian Weisgerber wrote:
Raimo Niskanen raimo+open...@erix.ericsson.se wrote:
A resembling application is the Git version control system that is
based on the assumption that all content blobs can be uniquely
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 the server is equal to
a part of a file in the client, if a hash value of these
Kenneth R Westerback kwesterb...@rogers.com 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.
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 the
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 as
Marc Espie es...@nerim.net 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
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net 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
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 es...@nerim.net wrote:
On Sat, Sep 14, 2013 at 04:13:41PM +, hru...@gmail.com wrote:
Marc Espie es...@nerim.net wrote:
On Sat, Sep 14, 2013 at
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
hru...@gmail.com 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
Marc Espie es...@nerim.net 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:
76 matches
Mail list logo
