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: Thu, 9 Jan 2014 13:46:31 -0500
From: Bill Cox <>
Subject: Re: [PHC] What's your favorite entry so far, and why?

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.

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.


Content of type "text/html" skipped

Powered by blists - more mailing lists