phc-discussions - Re: [PHC] "Attack on the iterative compression function"

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: Sun, 19 Apr 2015 03:57:26 +0300
From: Solar Designer <solar@...nwall.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] "Attack on the iterative compression function"

On Sun, Apr 19, 2015 at 03:49:34AM +0300, Solar Designer wrote:
> BTW, I don't see where the computation penalty of 1135 for 1/4 in the
> paper came from.  The program gave me 1254.56 even before I patched the
> higher-precision value in place of 1.33.  Maybe there's precision loss
> elsewhere in the program.  Maybe it should use double instead of float.
> (A quick "#define float double" right after the #include's resulted in
> compile errors, and I'm lazy.)  The 1135 vs. 1255 (or 1262) difference
> does not really matter for this discussion, but it means there may be
> worse precision loss for some other results.
> 
> ... rebuilt with -O3 instead of -O2, got 1290.28 there.  Added
> -ffast-math on top of that, got 1244.30.  This program is definitely
> having precision loss issues.

Oh, not necessarily.  This may explain it:

	mtr.seed(time(0));

The results actually vary a little bit between invocations.  I still
can't get anything below 1200, though.

Alexander