On Thu, Feb 23, 2017 at 05:01:56PM -0700, Warren Young wrote:
> Second, there will be those who say we’ve covered all of this already,
> multiple times.  I know, I was there.  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. That's really not all that much, contrary to all the
ranting going on right now.

Fossil had "hash collissions" issues for a long time and I'm not even
talking about this kind of issues. It might be a good idea to change the
storage format for new blobs and optionally provide a one time
conversion option. But I don't have the time to implement that.

The new stored blob should be:
- hash of the rest of the blob
- blob type
- content size
- content

The idea is that object id is the hash of everything. This should be
much more resilient to preimage attacks based on the block structure of
the hash function. I haven't had a chance to talk with a real
cryptographer about this yet, though. Including the blob type makes it
more robust and can significantly cut down in the parsing time on
rebuilds. Including the content size is just another way of making
meaningful preimage attacks somewhat harder.

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

Reply via email to