Re: [fossil-users] Is Fossil Hash-collision proof?

2017-03-22 Thread Richard Hipp 
On 3/22/17, Scott Robison  wrote:
>
> Let's say for the sake of argument that you somehow wind up with two
> modified files in the same commit that have the same hash but different
> contents. Fossil will read back the data it just wrote to ensure what went
> into the repo can be correctly retrieved. One of the two files will fail,
> and fossil will refuse to commit the data will a message. At that point you
> can change a file in some little way to get past the problem.
>
> In any case, fossil won't allow you to commit two files with the same hash
> given its verification steps.

Scott is completely correct.

I just want to emphasize his "for the sake of argument".  Though it is
possible *in theory* to generate a collision, that is impossible in
practice now that Fossil has switched to using Hardened-SHA1 instead
of SHA1, and is especially impossible when using SHA3-256.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is Fossil Hash-collision proof?

2017-03-22 Thread Scott Robison 
On Mar 21, 2017 11:04 PM, "Martin Vahi"  wrote:



I haven't encountered any collisions yet, but
I was wondering, what will happen, if 2 different
files that have the same size, same timestamps,
different bitstreams, but the same hash (regardless of hash algorithm)
were to be committed simultaneously, at the same commit?


Let's say for the sake of argument that you somehow wind up with two
modified files in the same commit that have the same hash but different
contents. Fossil will read back the data it just wrote to ensure what went
into the repo can be correctly retrieved. One of the two files will fail,
and fossil will refuse to commit the data will a message. At that point you
can change a file in some little way to get past the problem.

In any case, fossil won't allow you to commit two files with the same hash
given its verification steps.


After all, it's the "improbable" corner cases that
accumulate and trash even those projects that are
not slammed together by sloppy-or-just-lacks-the-self-esteem-to-care
type of developers. Everything works fine for a
long-long-long period of time, until one day, in the midst
of being overwhelmed with some other task that
uses software X as one of its main tools...

Thank You.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Is Fossil Hash-collision proof?

2017-03-21 Thread Warren Young 
On Mar 21, 2017, at 11:04 PM, Martin Vahi  wrote:
> 
> I haven't encountered any collisions yet

Nor are you likely to by accident, ever.

The only reason it’s even a concern is that a motivated attacker with lots of 
money could force a collision with the old SHA-1 algorithm.  It’s believed to 
be essentially impossible with the new SHA-3 algorithm.

> I was wondering, what will happen, if 2 different
> files that have the same size, same timestamps,
> different bitstreams, but the same hash (regardless of hash algorithm)
> were to be committed simultaneously, at the same commit?

There is no “simultaneously.”  SQLite has locking and transactions that prevent 
multiple simultaneous writes to the same table.  Therefore, one commit will 
happen, then the other will be rejected because Fossil says “I already have an 
artifact with that ID.”

The only known way to make use of a hash collision is to MITM the sync stream 
and substitute a bad artifact for a good one when the receiving repository 
doesn’t have the good artifact yet.  (e.g. On initial clone.)

Since even under SHA-1, a collision currently takes something like $100,000 and 
one month of compute time to produce, that means you can’t currently cause this 
to happen at all if everyone is syncing at least monthly. 

That time will shrink, but if all clients are using Fossil 2.0 or higher, even 
with SHA-1 we now have the protection of the Hardened SHA-1 algorithm, which 
closes all known holes in SHA-1 that make it possible to produce collisions 
even with $100,000 and a month of compute time.

> After all, it's the "improbable" corner cases that
> accumulate

In the case of SHA-3, we’re probably talking “not even until the heat death of 
the universe” levels of “improbable.”  You might as well worry over the 
possibility of the Sun quantum tunneling into the gap between the moon-Earth 
orbit.  Possible?  Yes.  Will it ever happen?  Not in a billion Big Bounces.

https://en.wikipedia.org/wiki/Big_Bounce

> Everything works fine for a
> long-long-long period of time, until one day, in the midst
> of being overwhelmed with some other task that
> uses software X as one of its main tools…

If you will not accept a statistical argument with cosmological odds against 
failure, what argument would you accept?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Is Fossil Hash-collision proof?

2017-03-21 Thread Martin Vahi 


I haven't encountered any collisions yet, but
I was wondering, what will happen, if 2 different
files that have the same size, same timestamps,
different bitstreams, but the same hash (regardless of hash algorithm)
were to be committed simultaneously, at the same commit?

After all, it's the "improbable" corner cases that
accumulate and trash even those projects that are
not slammed together by sloppy-or-just-lacks-the-self-esteem-to-care
type of developers. Everything works fine for a
long-long-long period of time, until one day, in the midst
of being overwhelmed with some other task that
uses software X as one of its main tools...

Thank You.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users