[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Showing progress during scrypt - how good is this idea?
- To: danielw@emaildoge.com
- Subject: Re: Showing progress during scrypt - how good is this idea?
- From: Dmitry Chestnykh <dmitry@codingrobots.com>
- Date: Tue, 30 Dec 2014 18:25:07 +0100
- Cc: scrypt@tarsnap.com
- In-reply-to: <d6c72b75c8a0b435d64a60b62bece243.squirrel@lelantoss7bcnwbv.onion>
- References: <d6c72b75c8a0b435d64a60b62bece243.squirrel@lelantoss7bcnwbv.onion>
> On 30 Dec 2014, at 17:43, danielw@emaildoge.com wrote:
>
> I want to show a percentage indicator during a lengthy scrypt process. The
> simplest idea I can think of is this:
>
> Pick N,r,p such that each crypto_scrypt() call is fast.
>
> Then repeat this same crypto_scrypt() call many times, passing the result
> of each crypto_scrypt() to the input (password) of the next
> crypto_scrypt(). The salt is kept the same for each call.
>
> The question is: Does this reduce security, as opposed to picking a larger
> p? In other words: Is picking p=1000 when calling crypto_scrypt() only
> once more secure than calling crypto_scrypt() with p=1 thousand times with
> the salt constant?
The major point of scrypt is sequential memory hardness, splitting it into many smaller, faster scryptinhos or picking too large ‘p’ will weaken this point.
(p is a parallelization parameter, you probably don’t want to make it too large today).
To give progress indication, you can split smix function into chunks, like I did in scrypt-async-js:
https://github.com/dchest/scrypt-async-js/blob/master/scrypt-async.js#L377
(While there’s no actual progress indication here [yet], splitting computation was a requirement to make JavaScript asynchronous.)
--
Dmitry Chestnykh
Coding Robots
http://www.codingrobots.com