[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] hash size
From:       jamesd () echeque ! com
Date:       2018-10-31 22:20:04
Message-ID: 5231547b-06b5-600f-71e0-a5cbc071dea7 () echeque ! com
[Download RAW message or body]

On 2018-11-01 06:49, Derek Atkins wrote:
> Worse, you'll have to
> explain to everyone, over-and-over, why you're not succeptible to
> collision attacks.  And then after you're done explaining, the next person
> will come up and ask again.
> 
> Worse, a 256-bit hash is pretty fast, so it's unclear what you're actually
> buying yourself with a 128-bit hash.

A block chain ledger should be implemented as a merkle patricia tree. 
You are buying a noticeable decrease in the size of that tree, and a 
corresponding increase in the speed at which a consensus can be generated.

But the speed improvement is only modest, and the human effort involved 
in discussing birthday attacks likely to be significant.

We need to ensure that it can never happen that two people see a 
different final consensus on which transactions are committed to the 
block chain, and which have been rolled back, but if the attack merely 
disrupts the process for generating that consensus with respect to the 
birthdayed transactions, a low value attack.  So 128 bit hashes are OK 
for flood filling transactions through the peers, but likely to be 
unacceptable for the authoritative merkle patricia tree of committed 
transactions.

But less coding effort and fewer bugs if we use the same hash 
throughout, and truncate them during the flood fill.

So yes, you are right.  Since we sometimes have to use a 256 bit hash, 
might as well use a 256 bit hash all the time, and truncate where the 
savings matter, and collision attacks do not.

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
[prev in list] [next in list] [prev in thread] [next in thread]