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: Mon, 7 Apr 2014 09:00:14 -0500 (CDT)
From: Steve Thomas <>
Subject: Re: [PHC] EARWORM (ROM hard is not enough)

> On April 7, 2014 at 8:39 AM Daniel Franke <> wrote:
> Steve Thomas <> 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.

Powered by blists - more mailing lists