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 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: Sun, 19 Apr 2015 05:57:12 +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:
> $ cat penalties-yes-multi.log
> Average Penalty for fraction 2 (104 close values): 2.96  Latency: 2.55 Read: 2.96
> Average Penalty for fraction 3 (133 close values): 26.69  Latency: 6.90 Read: 26.69
> Average Penalty for fraction 4 (176 close values): 1262.15  Latency: 17.37 Read: 1262.15
> Average Penalty for fraction 5 (233 close values): 416359.53  Latency: 40.80 Read: 416359.53
> Average Penalty for fraction 6 (323 close values): 1620898688.00  Latency: 86.20 Read: 1620898688.00

BTW, with Wrap() replaced with simple modulo division, the penalties are
in fact a lot lower starting with 1/3 memory:

Average Penalty for fraction 2 (100 close values): 2.82  Latency: 2.46 Read: 2.82
Average Penalty for fraction 3 (110 close values): 12.75  Latency: 5.35 Read: 12.75
Average Penalty for fraction 4 (145 close values): 163.08  Latency: 11.79 Read: 163.08
Average Penalty for fraction 5 (207 close values): 8574.96  Latency: 26.13 Read: 8574.96
Average Penalty for fraction 6 (277 close values): 2511368.25  Latency: 54.22 Read: 2511368.25

So it looks like Wrap() helps as it should (and it avoids the need for
modulo division, which would have been an extra source of timing leaks).

Alexander