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: Fri, 10 Jan 2014 10:01:48 +0000
From: Peter Maxwell <>
Subject: Re: [PHC] What's your favorite entry so far, and why?

On 9 January 2014 18:46, Bill Cox <> wrote:

> On Thu, Jan 9, 2014 at 12:06 PM, Peter Maxwell <>wrote:
>> What sort of size of memory requirement does one actually need to impose
>> to cause difficulty for i. GPUs, ii. FPGA/ASICs?
> There are basically two thresholds.  It hurts a lot when we bust out of
> on-chip memory for any of these technologies.  Currently, that thresho
> GPU: 64KB L1, 1.5MB L2  (GeForece GTX TITAN)
> FPGA: 14MB block RAM   (Xilinx Vertex UltraScale)
> ASIC: 24MB                      (Xeon E7)
> This on-chip memory is very expensive, so a KDF using low memory, like
> 10MB, should be super-fast and do lots of random accesses and sequential
> operations.  However, an ASIC run a lot faster than our CPUs, so you wont
> tie up that ASIC doing a password guess for long.

​Thanks - that's really useful.​  So to thwart a GPU style attack at the
moment is fairly easy but the FPGA/ASIC minimum lower bound is a fair bit
higher than I had expected (I was thinking ~10Mb range but looks like 32Mb
or thereabouts is going to be the minimum).

> Once you are over about 30MB, you're in off-chip territory, meaning it's
> stored in something like GDDR5 for a GPU, or DDR3 for an ASIC or FPGA.  An
> attacker has to pay basically the same as you and I for this memory, and
> there are bandwidth limitations:
> Desktop Computer:    25 GB/s
> High end GPU:          200 GB/s
> FPGA:                      256 GB/s
> ASIC:                       256 GB/s
> Basically, these GPUs and FPGAs are as expensive as a desktop computer,
> but they deliver 10X the memory bandwidth.  Filling up that bandwidth may
> be the best defense against hardware-based attackers.  The custom ASIC
> could possibly be cheaper, but there's a huge up-front cost.  Keeping
> attackers stuck at only a 10X cost*time advantage seems doable.  That's a
> lot of protection for all those really bad passwords out there.
> ​
Normally I'd have said an ASIC implementation would be unlikely but ​given
scrypt has already been implemented in ASIC for mining Litecoin* we can
probably work under the assumption that it may be a threat.

​[*] - I think it quoted around 25m scrypt hashes per second​, which
although isn't fantastic and I think at least 2 orders of magnitude lower
than GPU implementations against common password hashes, it's likely to get

Content of type "text/html" skipped

Powered by blists - more mailing lists