-----Original Message-----
From: Warren Young
On Feb 26, 2017, at 6:34 PM, Tony Papadimitriou <to...@acm.org> wrote:
how is it possible for someone to inject a 'bad' file with the same SHA1
as a 'good' file already in the repo?
Your attacker could be MITM’d into the sync stream. I gave an example
requiring only the current SHA-1 collision technology in my first reply in
the other thread:
So now HTTPS is also broken?
The only ways I can imagine
That’s because you aren’t a highly motivated, highly resourced, highly
trained black hat. But such people do exist.
I was implying 'practical' ways, not theoretical. Now, if Google wants to
use its billions to break my repo, they may do it, but it would be easier
for them to try to buy it from me for much less!
So, do you actually know of some other practical ways, or just looking to
make conversation?
I believe it will be really-really difficult (for the foreseeable future
at least) for someone to come up with a 'bad' file with both SHA1 and MD5
being the same.
Given that an MD5 collision costs less than 65 cents US to create these
days,[3] I think your premise is flawed.
You think, I think, who cares? Can you prove your point by providing such a
collision while we're still alive?
Yes, creating a collision in both MD5 and SHA-1 is probably more expensive
than the addition of the two (US $100000.65) but I don’t think you can say
that MD5 is adding meaningful security here.
MD5 is broken, broken, broken.[4]
So, if I give you a random piece of source code you (or your rich friends)
can create a matching paired-SHA1-MD5 alternate version (while we're still
alive)?
You would probably make bigger headlines than Google is making right now.
One would still need to match both SHA1 and MD5 to inject -- not easy!
Argument from incredulity.[5]
Ditto! (Or prove how easy it is!)
may introduce (an avalanche[?] of) bugs, and possibly even risk the
integrity of our current repos until fully bug-free.
Have avalanches of bugs been a notable hallmark of Fossil and SQLite, in
your experience?
Past success rates do not guarantee future ones (slightly modified from a
bank fine print warning).
(I for one would be reluctant to try it for actual work until enough
other people have used it for some time without problems.)
That’s why the SQLite project dogfoods trunk Fossil, and drh encourages us
end users to use Fossil from trunk, too. By the time Fossil 2.0 is
released, it *will* be well-tested, both formally and informally.
Actually, it's quite common that trunk fossil uses alpha and beta versions
of SQLite3 for the benefit of test-driving SQLite3. So, regardless any
assurances to the contrary, it's still a bit risky.
you can't really get the whole population to switch at the exact same
time.
We have decades of experience managing such problems.
But ... you are so Young. :)
Less arrogant people with decades of experience also created MD5, SHA1, ...
Not a very comforting argument at this point, is it?
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
