phc-discussions - Re: [PHC] EARWORM (ROM hard is not enough)

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: <1138070349.1177486.1396879214749.open-xchange@email.1and1.com>
Date: Mon, 7 Apr 2014 09:00:14 -0500 (CDT)
From: Steve Thomas <steve@...tu.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] EARWORM (ROM hard is not enough)

> On April 7, 2014 at 8:39 AM Daniel Franke <dfoxfranke@...il.com> wrote:
>
> Steve Thomas <steve@...tu.com> writes:
>
> > The problem I have with EARWORM is that it's only good if the ROM is too
> > big to fit in GPU memory. Currently we have high-end GPUs starting at 4 GiB
> > with 12 GiB being the max (right?). You only need one copy of the ROM in
> > GPU memory and since the state per each password guess is small (64 bytes)
> > you can have several passwords being checked at the same time.
>
> Yes, but only up the limit of available memory bandwidth, which on CPUs
> you hit very quickly because EARWORM's inner loop is so fast. Defenders
> can compute multiple workunits in parallel if one thread isn't enough to
> saturate their memory bandwidth.
>
> GPUs typically have more memory bandwidth available, but they're pretty
> bad at AES because the table lookups are slow. If you want to cause
> EARWORM some grief, figure out how to make a bitsliced implementation
> of it that's able to saturate GPU memory bandwidth.

That's not necessary the case the R9 290X has 320 GB/s bandwidth and
DDR3-2133 has 17.066 GB/s. That's 18.75 times more bandwidth and like 352
times more cores (2816 vs 8). I'm thinking that's enough for the GPU to
saturate bandwidth, but I guess the only way to find out is to test it.
Also I have not written AES for GPUs yet so this might not be the case. It
just seems like it to me.