phc-discussions - Re: [PHC] Native server relief support for password hashing in browsers

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]

Message-ID: <52DC052A.4070608@uni-weimar.de>
Date: Sun, 19 Jan 2014 18:02:34 +0100
From: Christian Forler <christian.forler@...-weimar.de>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Native server relief support for password hashing in browsers

On 19.01.2014 13:47, Bill Cox wrote:

[...]

> Catena focuses on an unrealistic weak attack against Scrypt: aborting
> the second loop early using cache timing.

We never claim that the cache-timing attacks against scrypt are practical.

"At the current point of time, our cache-timing attacks are theoretical.
Even if one manages to run some spy process on a machine using scrypt,
the requirement to interrupt ROMix twice at the right points of time is
demanding. Nevertheless, even the theoretical ability of mounting such
attacks should be seriously taken into account."

> However, an attacker still has to execute the full compute
> intensive first loop, so we're not talking about speeding anything up,
> just saving memory.  

False.

The regular cost to check an password candidate is
    T(n) = O(N^2) / S(n).

Our attack allows to check password candidate with
	T(n)  =  O(N)/ 1.

This is an dramatic improvement and it invalidates the memory-hardness
assumption of scrypt. It enables  a GPU attacker to test password
candidates in an "very efficient" way.

Best regards,
Christian

Download attachment "signature.asc" of type "application/pgp-signature" (535 bytes)