Re: [9fans] SHA-1 collision and venti

[Bakul Shah <bakul@bitblocks.com>]

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2746 bytes --]