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: Fri, 4 Apr 2014 08:19:15 +1000
From: Rade Vuckovac <rade.vuckovac@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Some Schvrch issues

Hi Bill



Thanks for your comments.



Especially thanks for pointing lapsus on line 107

(The proof that I can err simple programs as well).

Line 107 should read:

state[j] ^= memstate[j * (i + 1)];

I will update reference code and corresponding vectors.



The security analysis pointer / reference for the stir and revolve
functions is mentioned in the submission (stir function subsection).



The evolve function is an attempt to emulate Wolfram's rule 30 (random
number generator in Wolfram's Mathematica).

What is behind the randomness of rule 30 and how it is related to the
evolve function in terms of cyclomatic complexity is presented in the paper
(see submission Appendix).



Regards, Rade


On Thu, Apr 3, 2014 at 1:21 PM, Bill Cox <waywardgeek@...il.com> wrote:

> 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
>

Content of type "text/html" skipped

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ