Re: A modification to scrypt to reduce side channel risk

[Arnold Reinhold <agr@me.com>]

On Dec 26, 2013, at 4:46 PM, Krisztián Pintér <pinterkr@gmail.com> wrote:

> 
> 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 security.
> 
> 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 finalists were ranked by hardware execution speed, with Kaccek being fastest. Perhaps the candidates with the worst hardware implementation performance relative to software should be reconsidered for use with PBKDF2.

Arnold Reinhold