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