[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <504D9AEE.70400@tarsnap.com>
Date: Mon, 10 Sep 2012 00:46:54 -0700
From: Colin Percival <cperciva@...snap.com>
To: crypt-dev@...ts.openwall.com
CC: Solar Designer <solar@...nwall.com>
Subject: Re: using scrypt for user authentication
On 09/09/12 18:24, Solar Designer wrote:
> On Sun, Sep 09, 2012 at 05:52:12PM -0700, Colin Percival wrote:
>> What sort of authentication servers are you running where you only have
>> 1 MB of RAM per CPU core?
>
> Not per CPU core, but maybe per concurrent authentication attempt - if
> concurrency is not limited. If we simply introduce scrypt as a
> supported crypt(3) flavor in an OS, then its memory usage needs to be
> sane in the event of occasional spikes in concurrent authentication
> attempts, including on rather small systems (e.g., 256 MB RAM VPSes).
If you're seeing enough concurrent authentication attempts that using
16 MB for each of them comes close to eating up your 256 MB of RAM, odds
are that they're simply never going to finish due to CPU utilization
alone...
> A solution to this could be limiting concurrency - perhaps to the number
> of CPU cores, as you suggest. I mentioned some approaches to this here:
>
> http://www.openwall.com/lists/crypt-dev/2011/05/12/4
>
> I'd appreciate your comments on this.
>
> For dedicated authentication servers at some specific organization, it
> can be a custom interface, so limiting the concurrency is easier - and
> much larger amounts of RAM may be used anyway.
I admit that I haven't given much thought to the details of integrating
scrypt into crypt(3), beyond noting that the "100 ms" parameters yield a
memory usage of 16 MB which seems unlikely to impose an excessive strain
on many systems.
The case which interests me more is the large websites which make a habit
of leaking millions of hashed passwords, and I would expect them to set
up internal scrypt-computation services.
>>> We might also want to have a tradeoff-defeating variation of scrypt, as
>>> Anthony Ferrara suggested or otherwise. It appears that this would make
>>> scrypt maybe a factor of 2 more resistant to attacks with current GPUs
>>> at Litecoin's low settings and perhaps a lot more at bigger settings
>>> (where the total GPU card's RAM size is more easily hit if the tradeoff
>>> is not used in an attack). Maybe this property should be configurable
>>> (a Boolean parameter, to be encoded along with the resulting encrypted
>>> data or password hash).
>>
>> This seems like an attempt to patch over the problem of "scrypt not being
>> used as intended".
>
> I am not proposing this as an alternative to using larger memory sizes
> (as intended). I am proposing it for use along with scrypt's intended
> settings. Due to the tradeoff, GPUs may be potentially reasonably
> usable for attacking scrypt even with large memory settings. If a user
> of scrypt (e.g., a sysadmin) doesn't expect to need to crack scrypt on
> GPUs (and most won't), the user will be able to turn the knob and make
> scrypt more GPU-unfriendly. Note that since GPUs are only efficient
> when a lot of parallelism is available, they're likely not reasonably
> usable for defensive scrypt computation anyway (unless "p" is set very
> high in advance).
Point taken... although one supposes that a GPU might be a solution to your
hypothesized denial-of-service attack problem. :-)
--
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.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.
