[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A modification to scrypt to reduce side channel risk
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
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.
Security Officer Emeritus, FreeBSD | The power to serve
Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid