[Cryptography] blake2b 160

[jamesd at echeque.com]

On 31/12/2018 00:03, Jonathan Thornburg wrote:
> On Sun, Dec 30, 2018 at 01:33:29PM +0800, 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.
> 
> What's your threat model?
> 
> If your thread model is truly "no one" and "ever", this is going to be
> very, very hard.
> 
> Ok, so let's relax the thread model to say that (as an approximation to
> "no one" and "ever") you want resistance to (say) the sort of effort the
> NSA might mount against a major Rusian or Chinese cryptosystem, i.e.,
> several hundred PhD-level researchers, a budget measured in billions of
> dollars, and a decade of effort.  And you don't care about the CPU/memory
> cost of computing the hash function.
> 
> So now you probably want to think very carefully before using the word
> "overkill" in your system design.
> 
> Are there any constraints on the colliding data blocks?  I.e., does the
> attacker have complete freedom to choose *any* data blocks in trying to
> construct a collision?


He has complete freedom to choose a twenty byte or so nonce.   And "He" 
might well have the computational resources of Google or the NSA

The threat is that he constructs two short messages, one of the 
transaction he wants, with a 20 byte nonce that he has complete freedom 
to choose. and one of the form the other guy wants, with a another 
twenty byte nonce that he has complete freedom to choose, and needs to 
get them to have the same hash


> 
> Can you combine multiple "good" hash functions in a way that makes the
> combination much harder to break than any individual one? 

You are raising  vast pile of unsolved and unsolvable theoretical issues 
with no obvious relevance to the question, the question being 
specifically about blake2b 160