[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 23 Jul 2018 21:41:35 +0200
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Cc: Denis Burykin <apingis@...nwall.net>
Subject: Re: sha512crypt & Drupal 7+ password cracking on FPGA
On Mon, Jul 23, 2018 at 08:40:48PM +0200, Jens Steube wrote:
> For sha512crypt I'm getting around 377kH/s on all four GPU. That
> translates to ~94300 per 90W.
> For Drupal7 I'm getting around 156kH/s on all four GPU. That translates
> to ~39000 per 90W.
>
> This is a weird result on the first look.
Why, it looks reasonable to me. Thanks for sharing it.
> If I understand your
> measurements correctly a single quad FPGA board is doing 54600H/s at 40W
> on sha512crypt and 16600H/s at 40W on Drupal7. If you scale this up to
> 90W, it's 122850H/s per sha512crypt and 37350H/s per Drupal7. That means
> from power consumption perspective it's 30% faster than the GPU for
> sha512crypt, but at the same time it's slower for Drupal7?
Right. Our sha512crypt and Drupal7 on FPGA are basically same speed in
terms of their underlying SHA-512 hashes computed per second. Like I
mentioned, our Drupal7 could have been more optimal in a specialized
design without support for unaligned access and maybe without the soft
CPUs at all (we could have freed up that logic to have up to 25% more
SHA-512 cores maybe), but we got it almost for free here (on top of the
sha512crypt design), so we're happy. On GPU, you actually take
advantage of Drupal7's relative simplicity, as you say:
> The reason
> here is the branches in the loop function in sha512crypt which is a
> special case. GPU's really don't like them.
Actually, when all passwords loaded on the GPU at once are of the same
length I guess the branches don't hurt much. What hurts is the need to
support unaligned accesses - and I guess you avoid this overhead in your
Drupal7 kernel.
> IOW, the GPU implementation
> for all *crypt algorithms is a bit below it's theoretical maximum. In
> Drupal7 (and PBKDF2 and most other KDF) there's no such branches in the
> loop thus the GPU can perform at full speed on all compute units.
>
> As you can see here the GPU of today are pretty close when it comes to
> power consumption to a FPGA board. I know that ztex boards are old now
> and that there's better solutions, but the same as with newer GPU, see
> alone the V100. I'm happy with the results.
Right. Spartan-6 was introduced in 2009(?) on a 45nm process, and as
budget series (Virtex-6 were larger and faster). NVIDIA Pascal was
introduced in 2016 and on a 16nm process. So there's bigger potential
for improvement by switching from Spartan-6 to current UltraScale+ FPGAs
(2016, 16nm) than from Pascal to Volta (2017-2018, 12nm).
V100 is about twice larger than GTX 1080. VU9P as offered on AWS F1 is
~16x larger than our Spartan-6 LX150 (so ~4x larger than our boards) and
also faster (we'll have higher clock rate - e.g., I saw mentions of it
running Keccak at 700+ MHz as a power consumption stress-test that
altcoin miners now use). And this isn't even the largest FPGA (but
apparently larger ones are unrealistic to cool at full utilization).
The drawback is price. Thousands of those boards tweaked for
cryptocurrency mining (lower core voltage, etc.) were recently offered
and quickly sold out to altcoin miners for $3600 each. Original are
called VCU1525, tweaked are BCU1525 - you might want to Google them and
the reported altcoin mining speeds vs. GPUs. I didn't look into this
closely yet, but if people are buying these then there must be
significant advantage.
Thanks again,
Alexander
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
