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:
https://news.ycombinator.com/item?id=13715887
As for the difficulty of MITM’ing your sync connection, are your Fossil servers
all behind strong TLS proxies? If not, your Fossil sync streams pretty
trivially MITM-able. And if you do use strong TLS, are you sure there are no
TLS-busting middleboxes[1] or broken antimalware tools[2] in the computer
networks at either end of the connection?
[1]: https://en.wikipedia.org/wiki/Middlebox
[2]: https://goo.gl/37H7pN
> 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.
> how urgent is the need to transition away from SHA1?
If we could magically upgrade all of the Fossil clients in the world, we could
wait until just before the sky actually begins to fall. That event is likely
years out.
If drh actually manages to ship a fix for this by Easter — aggressive, but
doable — then we’ll still be seeing Fossil 1.x on a fair number of systems on
Easter of 2022, by which time the current attack could be either 5-10x faster
or 5-10x cheaper, the factor depending on whether there are further
breakthroughs in that time. I think we should count on 10x and be pleasantly
surprised if it’s “only” 5x.
Moore’s Law may be running out of steam for general purpose computing, but not
for embarrassingly parallel applications like hash collision searching.
> 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.
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]
[3]: https://natmchugh.blogspot.com/2015/02/create-your-own-md5-collisions.html
[4]: https://eprint.iacr.org/2013/170.pdf
> Don't tell me MD5 is broken.
MD5 is broken. :)
> One would still need to match both SHA1 and MD5 to inject -- not easy!
Argument from incredulity.[5]
[5]: http://rationalwiki.org/wiki/Argument_from_incredulity
> 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?
> (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.
> you can't really get the whole population to switch at the exact same time.
We have decades of experience managing such problems. This is known tech. We
don’t need to invent any new wheels here.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
