Re: A modification to scrypt to reduce side channel risk

[Colin Percival <cperciva@tarsnap.com>]

On 12/26/13 13:46, Krisztián Pintér wrote:
> Arnold Reinhold (at Thursday, December 26, 2013, 9:29:24 PM):
>> But PBKDF2 is not transistor hungry.
> 
> it is. if you double the iteration count, you effectively double the
> necessary hw to break it (because you need twice as many units to
> deliver the crack in the same time frame). it is the same as with
> scrypt.

No.  Increasing N by a factor of 2 makes the area-time cost of scrypt
increase by a factor of 4.

>> 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.

Yes.  This would severely weaken the algorithm.

-- 
Colin Percival
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid