phc-discussions - Some Schvrch issues

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-next>] [day] [month] [year] [list]

Message-ID: <CAOLP8p6ooqdOVR3zTLsDvaFB-C4ykOjmZadc5T48nde7s2_JfA@mail.gmail.com>
Date: Wed, 2 Apr 2014 23:21:10 -0400
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Some Schvrch issues

Here's some issues I think I see in this PHC entry.

The average memory*time cost can be very low for very high time cost
parameters, since only the state is hashed in the time cost loop.
Large amounts of memory are only hashed in the second memory hashing
loop.

No cryptographic hash primitives are used, meaning this entry will
have to pass a higher bar for security analysis.

The evolve function seems to do very little mixing.  No matter how
long it runs (it runs 2*statelen^2), the result is a simple linear
combination of the original states, and a pseudo-random bitwise
complement.  For example, starting with all 0's results in each state
value being either 0 or -1 (all 1's).  This does not give me much of
that confidence I would look for given the lack of a secure
cryptographic hash.

There is an error on line 107.  Did he mean to XOR into the state
rather than overwrite it?

Bill