[Cryptography] blake2b 160

[jamesd at echeque.com]

On 31/12/2018 04:51, Ray Dillinger wrote:
> 
> 
> On 12/29/18 9:33 PM, jamesd at echeque.com wrote:
>> I have an application that requires that no one can ever produce a hash
>> collision on two data blocks of moderate size.
>>
>> Seems to me that Blake2b 160 suffices, and Blake2b 256 is overkill.
>>
>> Someone claimed its easy to produce collisions and sprayed what sounded
>> to me like random technobabble in support of that claim.
>>
>> So, for a given number of bits in the hash, how much time and resources
>> are required to produce two blocks of data of moderate size such that
>> the last n bits of the hash are the same for both blocks?
> 
> Pretty hard.  I don't think you have anything to worry about, although
> I'd probably have reflexively picked 256-bit.  Is a post-quantum
> future part of your design requirements?  I think quantum gives a
> marginal speedup on Blake, but not by more than a fairly small constant
> factor.
> 
> I worry about hashes because the vast majority, including BLAKE and
> variants, are subject to length-extension attacks.  That is, if you can
> find a string that matches the hash of any prefix of the message, then
> the remainder of the message can be appended to it resulting in a
> collision on the whole message.  So there is an attack surface at every
> block (at the end of every prefix), not just at the final block.

Thank you.

This confirms my expectation that Blake2b 160 will suffice, since all 
messages will be short, and all messages will have a prefix that defines 
their schema, and thus implicitly their length, and, as in SHA 256, an 
affix specifying their actual length.  (In blake2b length affix every 
chunk, not just at the end, so that hashing is not position invariant.)