My argument is that an archival system that can't store some files, no matter how they were generated, is not good enough. A hash collision researcher may have a legitimate reason to store such files.
> On Feb 27, 2017, at 9:07 AM, Charles Forsyth <charles.fors...@gmail.com> > wrote: > > >> On 27 February 2017 at 16:47, Charles Forsyth <charles.fors...@gmail.com> >> wrote: >>> On 27 February 2017 at 15:46, Dave MacFarlane <driu...@gmail.com> wrote: >>> Why not skip sha-256 and go directly to Sha3? >> >> blake2 has also been suggested > > also, it's not clear it's urgent for venti. the scam is to make a new value > that produces the same hash as an earlier important value where the hash > plays a part in certifying the value, > or where software uses the shorthand of comparing hashes to compare values > and acts on that without comparing the values. > with venti, the hash is produced as a side-effect of storing a value, and it > also records the value itself. > when the hash is presented, the stored block is returned. the hash itself is > a compact address and doesn't certify the value (ie, nothing that uses venti > assumes that it also certifies the value). > any attempt to store a different value with the same hash will be detected. > using any hash function has a chance of collision (newer, longer hashes > reduce that, but it's rare as it is). > because venti is write-once, no-one can change your venti contents subtly > without access to the storage device, but if they've got access to the > storage they don't need to be subtle. > with the collision-maker and access to the storage device, they can make a > previously certain vac: mean something different, but it still needs raw > access to the device, it can't be done through > the venti protocol.
