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.forsyth@gmail.com> wrote:

On 27 February 2017 at 16:47, Charles Forsyth <charles.forsyth@gmail.com> wrote:

On 27 February 2017 at 15:46, Dave MacFarlane <driusan@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.