Closed thinkloop closed 8 years ago
It's mentioned in README:
Limitation Doesn't support parallelization parameter greater than 1.
Adding support for p would add a lot to the complexity of the async loop, so I just skipped it. It's useless in JavaScript anyway — the processing would be parallel, just like in the reference implementation, unless you support it via Web Workers, but since this library was meant to be compatible with older browsers, I couldn't rely on them.
That said, I'd accept pull request if someone implemented it.
OK, thanks for the reply.
I am trying to match the results with node reference implementation: https://github.com/barrysteyn/node-scrypt
But I am unable to get the same results, even with p = 1. Any idea what would be the equivalent of:
scrypt.hashSync(password, {"N":65536,"r":1,"p":1}, 32, salt)
The result using the following params:
var password = 'aaaa';
var salt = 'bbbb';
scrypt.hashSync(password, {"N":65536,"r":1,"p":1}, 32, salt);
Should be:
252a117b59b5034603c8a38f04c6e5b0ffe28b87617bbfb59c5f22d51524303c
Should be: logN = 16, r = 1
scrypt(password, salt, 16, 1, 32, callback)
(r = 1, BTW, is not good, should be 8 for now.)
That worked, thanks!
@dchest from https://www.tarsnap.com/scrypt/scrypt.pdf "Note also that since the computations of SMix are independent, a large value of p can be used to increase the computational cost of scrypt without increasing the memory usage"
it would be really valuable to have such a support in the library in order to be able too fine tune the algorithm properly; in many use cases (when the library is used in the browser) the memory is really limited and capped by the general purpose compute and so logN cannot be set that big, and on such a condition one could benefit of adding some CPU complexity.
Yeah, I'd like to implement parallelization parameter one day, but this will most likely happen in a new library I'm currently writing (although I'll probably accept a pull request). Here I just removed it for simplicity of implementation, as interrupted async loop is already crazy enough.
The thing is that each p
is intended to load one CPU thread, so the proper implementation would use a web worker for each computation. (Although, even the reference implementation doesn't implement parallelization yet!) However, if we have access to web workers, we don't even need the complexity of scrypt-async
, we can just make scrypt
synchronous and put the whole scrypt computation into a web worker.
The ethereum blockchain requires p be over 1 for certain values, and web workers will take a while for wide-spread support, there's a nice little niche spot for single-threaded chunked variable p scrypt'ing. Just showing a case for demand, not asking for free work :D. All the best.
On Wed, Jun 22, 2016 at 5:40 AM, Dmitry Chestnykh notifications@github.com wrote:
Yeah, I'd like to implement parallelization parameter one day, but this will happen in a new library I'm currently writing (although I'll probably accept a pull request). Here I just removed it for simplicity of implementation, as interrupted async loop is already crazy enough.
The thing is that each p is intended to load one CPU thread, so the proper implementation would use a web worker for each computation. (Although, even the reference implementation doesn't implement parallelization yet!) However, if we have access to web workers, we don't even need the complexity of scrypt-async, we can just make scrypt synchronous and put the whole scrypt computation into a web worker.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/dchest/scrypt-async-js/issues/22#issuecomment-227693991, or mute the thread https://github.com/notifications/unsubscribe/AAHQHnT6eSQzjhdwgybUofwE1EJHku7Vks5qOQMmgaJpZM4HmUft .
Hey thanks for the lib!
How come there is no param for
p
in the usual scryptN, r, p
?For example, from the node.js reference implementation:
https://github.com/barrysteyn/node-scrypt#test-vector-1
Thanks!