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  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 08:40:40 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] What's your favorite entry so far, and why?

>
> 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).
>

The 10MB range protects against low-end FPGA attacks and also cheaper ASICs
built in non-cutting-edge processes.  That Virtex part is a die-stacked
monster that will cost you > $1,000.  A 20nm ASIC will cost you millions
just to get your first part.  A more cost effective threat is probably 10
$100 FPGAs in parallel, and they'll have a lot less memory than 10MB each.

There is a sweet spot in trying to fit in a server's cache while busting
out of GPU and even most FPGA on-chip memory.  For server-side KDF, it's
not a bad solution.  For server-side, I'd like to see  extra protection in
the form of the blakerypt-style master keys that never hit disk, because a
server database is a far higher value target than a user's PC, and that
low-memory KDF is weaker than what a user can do on his PC.

For running on a user's PC, in applications such as file encryption, I
think we should take advantage of the memory bandwidth ratios to limit an
attacker to 10X-ish in price-performance advantage.  Cache resident KDFs
will not get us there.  The best protection for single-user machines is to
hammer the DRAM interface, IMO.

Bill

Content of type "text/html" skipped

Powered by blists - more mailing lists