[148771] in cryptography@c2.net mail archive
Re: [Cryptography] A modification to scrypt to reduce side channel
daemon@ATHENA.MIT.EDU (Bill Cox)
Fri Dec 27 12:09:06 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <CAOLP8p6MHkcOOerx7NqFqDMiRK2Wv-AtSX-EjO1GNqX4+E_BQw@mail.gmail.com>
Date: Fri, 27 Dec 2013 09:59:04 -0500
From: Bill Cox <waywardgeek@gmail.com>
To: Cryptography <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3994662968812767454==
Content-Type: multipart/alternative; boundary=f46d0444ea99ce336904ee8555d9
--f46d0444ea99ce336904ee8555d9
Content-Type: text/plain; charset=ISO-8859-1
D'oh! The data written to memory MUST rely on the password! This was a
good idea (the topic of this thread), but we require both the salt and
password to initialize memory.
The reason is simple, and now I feel dumb (happens a lot I'm afraid).
After initializing memory just based on salt, we take a random walk
through memory just based on salt to pick data to hash. An attacker just
feeds the resulting hash stream to a million super-cheap password guessers,
none of which need significant memory.
Maybe this is what you guys meant when you said step 3 can be done in
parallel.
In any case, we must initialize memory with the intermediate derived key,
but we don't have to rely on the password to generate the random walk. We
can do that with just the salt, and I think that results in better security
against timing attacks.
--f46d0444ea99ce336904ee8555d9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra">D'oh! =A0The data written t=
o memory MUST rely on the password! =A0This was a good idea (the topic of t=
his thread), but we require both the salt and password to initialize memory=
.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The reason =
is simple, and now I feel dumb (happens a lot I'm afraid). =A0After ini=
tializing memory just based on salt, we take a random walk through memory j=
ust based on salt to pick data to hash. =A0An attacker just feeds the resul=
ting hash stream to a million super-cheap password guessers, none of which =
need significant memory.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Maybe this =
is what you guys meant when you said step 3 can be done in parallel.</div><=
div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">In any case,=
we must initialize memory with the intermediate derived key, but we don=
9;t have to rely on the password to generate the random walk. =A0We can do =
that with just the salt, and I think that results in better security agains=
t timing attacks.</div>
</div>
--f46d0444ea99ce336904ee8555d9--
--===============3994662968812767454==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============3994662968812767454==--
