[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4E0D1941.1070406@tarsnap.com>
Date: Thu, 30 Jun 2011 17:48:01 -0700
From: Colin Percival <cperciva@...snap.com>
To: Solar Designer <solar@...nwall.com>
CC: scrypt@...snap.com, crypt-dev@...ts.openwall.com
Subject: Re: scrypt time-memory tradeoff
On 06/30/11 17:39, Solar Designer wrote:
> Colin, all -
>
> This is probably nothing new to you, but here's some analysis Anthony
> Ferrara (ircmaxell) posted regarding an attacker making scrypt run in a
> lot less memory, by trading CPU/GPU time for that:
Yes... I think I explicitly mentioned that in my paper, in fact. ;-)
The design of scrypt puts a lower bound on the area-time product -- you can
use less memory and more CPU time, but the ratios stay within a constant
factor of each other, so for the worst-case attacker (ASICs) the cost per
password attempted stays the same.
I'm actually planning on adding this support to my scrypt code, in order to
avoid the "you don't have enough RAM to compute this hash" error; but I
haven't had the time yet.
--
Colin Percival
Security Officer, FreeBSD | freebsd.org | The power to serve
Founder / author, Tarsnap | tarsnap.com | Online backups for the truly paranoid
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
