lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 23 Apr 2014 14:33:20 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Dumb fast file digest idea...

Hi, Dmitry.  I made a mistake above.  Blake2b has a 1,024 bit state
internally.  If I only XOR 512 bits of input data per round into the 1024
bits of state, making it hard to control the resulting hash value, does
that hamper your attack?

I think there are various possibilities for hashing functions like the one
above.  For example, how about using a large block hash function more like:

hashBlock(uint512 block[128], uint1024 state) {
    state1 = state
    state2 = state ^ RAND_CONST
    for(i = 0; i < 128; i++) {
        state1 = Blake2b_ROUND(state1, block[i])
        state2 = Blake2b_Inverse_ROUND(state2, block[127-i])
    }
    // Full Blake2b hash to combine state1 and state2
    return Blake2b(Blake2b(state1, low(state2)), high(state2))
}

This function hashes the data in opposite directions from both ends.  An
attacker trying to do anything at the end of one chain winds up changing
the start of the other, which cascades through a lot of rounds.  Can you
see flaws in this?

Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists