phc-discussions - Re: [PHC] Dumb fast file digest idea...

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 linux-cve-announce 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