[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 16 Nov 2012 07:47:15 +0400
From: Solar Designer <solar@...nwall.com>
To: Colin Percival <cperciva@...snap.com>
Cc: crypt-dev@...ts.openwall.com
Subject: Re: using scrypt for user authentication
On Mon, Oct 01, 2012 at 10:56:33AM +0400, Solar Designer wrote:
> Correction: once I've excluded some overhead and system time from my
> measurements, I am able to go to 256 MB with salsa20_8() NOP'ed out, yet
> stay under 100 ms. I am not sure if avoiding the system time would be
> possible in actual use, though - I just presume that it might be.
>
> This is (2^18, 8, 1) with salsa20_8() NOP'ed out on E5649 (2.53 GHz):
>
> real 0m0.240s
> user 0m0.080s
> sys 0m0.159s
I think I need to clarify:
Fully NOP'ing out salsa20_8() resulted in a non-random access pattern to
V, which made unrealistically good use of caches. So it tells us how
fast the remaining code can work when accessing caches rather than RAM.
It does not mean we can actually use 256 MB in under 100ms, even with a
very fast data mixing function, if that function actually works.
> At 2 rounds of Salsa20 (instead of 8), I am still only able to go for 64 MB:
>
> (2^16, 8, 1), 2 rounds, same CPU:
>
> real 0m0.124s
> user 0m0.087s
> sys 0m0.037s
>
> (2^15, 8, 1), 8 rounds (default), same CPU:
>
> real 0m0.121s
> user 0m0.100s
> sys 0m0.020s
Alexander
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.
