Re: parallelism in a single instance of scrypt

[Colin Percival <cperciva@tarsnap.com>]

Solar Designer wrote:
> How much parallelism is there in a single instance of the scrypt key
> derivation function?

One salsa20/8 core worth, i.e., pretty much what modern CPUs provide,
plus explicit parallelism via the parameter $p$.

> How much pressure does scrypt place on the memory bus?

This depends on the parameter $r$ and how much cache you have.  On all
systems I'm aware of, you can make scrypt CPU-bound, which is what you
want in order to maximize the hadware cost.

> Ideally, a key derivation function should be able to
> optimally use the hardware (all of: CPUs, GPUs, buses, memory) for a
> _single_ instance of it on any common system that it is run on (of
> course, the parameters may need to be tweaked by the system admin) - but
> this goal is very hard to achieve.  Somehow I haven't seen the paper,
> nor the slides, try to address this trade-off dilemma.  Have I missed it?

Using resources other than {CPU, RAM} would dramatically increase the
complexity of the KDF without providing a significant benefit, especially
if you want to get reasonably constant performance across similar generations
of systems.  GPUs vary too much to be really useful here.

-- 
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid