On Fri, Feb 24, 2017 at 03:54:56PM -0700, Warren Young wrote: > On Feb 24, 2017, at 10:37 AM, Joerg Sonnenberger <[email protected]> wrote: > > > > On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote: > >> But now we have new data. > >> Before, this sort of attack was theoretical only. Now it’s not only > >> proven possible, it is already within the ROI budget for certain > >> specialized attacks; attacks only get cheaper over time. > > > > Actually, the only thing that changed is that the attack now has a > > decent price tag. > > We also know it can happen before most of our respective careers are > over, so it isn’t something we can boot down the road to the next generation.
The attack itself hasn't add anything significant to the SHA1 attack knowledge AFAICT. As such, it is a good implementation of what has been known already. Seriously, the only real surprise is the price tag. > > Fossil had "hash collissions" issues for a long time > > Really? Fossil has a very nice status page showing what your current > repository is doing in this regard: Admin > Reports > SHA1 Collisions. Completely different thing. > But this report only tells you about accidental collisions, whereas the > SHAttered attack is about creating purposeful collisions. Ever tried attaching an existing commit manifest to a bug report or committing it locally and then rebuilding the repo? > > The new stored blob should be: > > - hash of the rest of the blob > > - blob type > > - content size > > - content > > What does the content size buy you? Making it more difficult to use payload-after-random-data attacks that exploit the block nature of many hash function constructions. This is the mechanism that allows stripping aligned suffixes from both documents without changing the status of the colliding hash. > The SHAttered attack shows that if you’re only after a collision, you > can maintain the file size while making your collision. Creating random collisions like in that is only of limited usefulness. More interesting attacks require tighter control. > If you’re trying to protect against preimage attacks with this > modification, the content size isn’t an independent variable with > respect to the content itself. I think if you asked a cryptographer, > they’d tell you it adds nothing to the robustness of the resulting hash. I didn't claim it to be. It is useful data to have access to as early as possible and it is a pesky consistency check, even if it doesn't provide any additional (theoretical) security. But it does help with some classes. > I also don’t see what hashing the blob data twice gets you. The hash > value changes, but again not as an independent variable. When you can create a hash collissions for the inner hash, it doesn't mean you have automatically a collission for the outer hash as well. You almost certainly do not. At the same time, creating a collission of the outer hash directly is much harder as you need to also compensate for the structure of the data to have a useful result. At the very least it means that the attacker has to do a full hash recomputation in every cycle and not just update the last block of a shared prefix. > If you want to make things more difficult, you could throw a timestamp > in there, as Git does. What timestamp again? Like the useless size data you just argued against? > > can significantly cut down in the parsing time on rebuilds. > > Why? If you’re trying to find data of a particular type in the DB, > doesn’t event.type tell you what you want to know without parsing cards? Well, where does that table get populated from after the initial clone? > What became of the idea of skipping rebuilds for very large repos, by > the way? Fossil rebuilds are strictly optional, aren’t they? Not at all. You have to rebuild at least once after the clone. Joerg _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
