[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <504DC71A.2000402@tarsnap.com>
Date: Mon, 10 Sep 2012 03:55:22 -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/10/12 02:29, Solar Designer wrote:
> On Mon, Sep 10, 2012 at 12:46:54AM -0700, Colin Percival wrote:
>> 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...
>
> This depends on duration of the spike in concurrent authentication
> attempts. For example, at 1 MB, if 50 concurrent attempts arrive, but
> are not followed by any more for at least a few seconds, the system will
> survive with no long-term impact on other running services. At 16 MB,
> it will temporarily fully run out of memory, so other services may be
> impacted (requiring restart).
True.
> [...]
> Anyhow, even if you convince me that scrypt at 16 MB is OK for crypt(3),
> we'd have a hard time convincing others of it. Besides, I'd consider
> using more than 16 MB if we limit concurrency.
I said 16 MB because that's what you end up using given the parameters
(N, r, p) = (2^14, 8, 1) which I mentioned in my paper as being good for
100 ms of KDF computation. Obviously that can be adjusted, but you can't
use more than 16 MB of RAM unless you spend longer than 100 ms (or have a
faster CPU than what I had in my laptop 3 years ago -- I'm guessing that
we're at 32 MB of RAM for 100 ms by now).
>> 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.
>
> Yes, this interests me as well. With proper concurrency limits, we
> could even use gigabytes of RAM per scrypt instance there. However,
> then it becomes challenging to keep the runtime per password hashed
> sane.
Depending on your value of "sane". There's a reason why my paper gives
examples of 100 ms for interactive logins and 5 s for file encryption.
--
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.
