Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<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

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ