[148761] in cryptography@c2.net mail archive
Re: [Cryptography] A modification to scrypt to reduce side channel
daemon@ATHENA.MIT.EDU (Arnold Reinhold)
Thu Dec 26 21:17:20 2013
X-Original-To: cryptography@metzdowd.com
From: Arnold Reinhold <agr@me.com>
In-reply-to: <15210210640.20131226224642@gmail.com>
Date: Thu, 26 Dec 2013 20:33:53 -0500
To: =?iso-8859-1?Q?Kriszti=E1n_Pint=E9r?= <pinterkr@gmail.com>
Cc: Cryptography <cryptography@metzdowd.com>, scrypt@tarsnap.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On Dec 26, 2013, at 4:46 PM, Kriszti=E1n Pint=E9r <pinterkr@gmail.com> wrot=
e:
> =
> Arnold Reinhold (at Thursday, December 26, 2013, 9:29:24 PM):
> ...
> =
>> I propose replacing P, the password or passphrase, in step 1 with
>> the null string. In other words all the memory banging in step 2
>> would be determined solely by the salt, S. The password would only
>> affect the algorithm output in step 3, which should be sufficient for se=
curity.
> =
> i believe this would severely reduce the hw cost, as you can share the
> prepared memory block between multiple cores executing the 3rd step.
You are correct. I should have known better. We are back to discussing use=
cases where the benefits outweigh the risks.
> =
> my main concern is that it still does not solve the bigger problem
> that is not just my personal crusade, but rather, a recognized issue.
> namely that the memory access pattern makes it susceptible to cache
> timing attacks.
> =
> i'm wondering whether it is possible to maintain seq mem hardness
> while having a fixed access pattern. i was thinking about gigantic
> versions of existing primitives, like a keccak[25*2^28]. is that seq
> mem hard? how close? i asked that on the PHC forum, but it did not
> spark a whole lot of discussion (aka zero).
Using a hash with a larger memory footprint could help. Also the SHA3 final=
ists were ranked by hardware execution speed, with Kaccek being fastest. Pe=
rhaps the candidates with the worst hardware implementation performance rel=
ative to software should be reconsidered for use with PBKDF2.
Arnold Reinhold
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
