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: <CAOLP8p7kzfbXJ96U6JFdZd5WUHiDvH2jj9psv8ohGOMuzmXbfg@mail.gmail.com>
Date: Tue, 14 Jan 2014 16:02:41 -0500
From: Bill Cox <waywardgeek@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] A must read...

On Tue, Jan 14, 2014 at 3:27 PM, Marsh Ray <maray@...rosoft.com> wrote:
>
>> Memory.  If each pipeline stage requires 500MB of DRAM, then this gets rather expensive.
>
> Looks like 500 MiB DDR3 is currently $4.22 retail. This doesn't sound cost-prohibitive to an attacker building their own custom ASIC. Pin count is likely to be the limiting factor in up-front costs, while power consumption costs are likely to dominate after few months of continuous operation.

You may be right that the cost of the ASIC or FPGA will dominate over
the memory cost if the ASIC or FPGA has a lot of DDR3 pins.  At a
minimum, even that $4 is a huge leap forward vs KDFs prior to scrypt.
My guess would be SHA-256 cores in 40nm or lower would cost at most
$0.01, and the ASIC could have many thousands of them while being in a
cheap wirebond package.

The memory size and bandwidth seems to be the key to increasing the
attacker's cost per core and defeating his ability to integrate
thousands of cores per chip.  I'm using multipliers in my KDF, and
even multipliers are cheap on-chip.  Serial multiplications force the
attacker to compute for a similar amount of time as me.  The high
memory bandwidth caps his ability to integrate and lower costs.  The
combination seems to maximize his cost*time.  We can do 100X better
than the default scrypt package in Arch Linux, and as script points
out, it does 20,000 times better than prior KDFs (other than bcrypt).

Bill

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ