phc-discussions - Re: [PHC] What's your favorite entry so far, and why?

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: <CA+aY-u6xGL4XmORsPZpk=pCZjzRdb2Y590sBVgO32V61DZNemw@mail.gmail.com>
Date: Fri, 10 Jan 2014 10:01:48 +0000
From: Peter Maxwell <peter@...icient.co.uk>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] What's your favorite entry so far, and why?

On 9 January 2014 18:46, Bill Cox <waywardgeek@...il.com> wrote:

> On Thu, Jan 9, 2014 at 12:06 PM, Peter Maxwell <peter@...icient.co.uk>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
better.

Content of type "text/html" skipped