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 <> 
> wrote:
>> On 27 February 2017 at 16:47, Charles Forsyth <> 
>> wrote:
>>> On 27 February 2017 at 15:46, Dave MacFarlane <> 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.

Reply via email to