dchest / scrypt-async-js

Fast "async" scrypt implementation in JavaScript
http://dchest.github.io/scrypt-async-js/
BSD 2-Clause "Simplified" License
139 stars 26 forks source link

Where is the "p" in N, r, p? #22

Closed thinkloop closed 8 years ago

thinkloop commented 8 years ago

Hey thanks for the lib!

How come there is no param for p in the usual scrypt N, r, p?

For example, from the node.js reference implementation:

scrypt.hashSync(key,{"N":16,"r":1,"p":1},64,"")

https://github.com/barrysteyn/node-scrypt#test-vector-1

Thanks!

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

thinkloop commented 8 years ago

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
dchest commented 8 years ago

Should be: logN = 16, r = 1

scrypt(password, salt, 16, 1, 32, callback)

(r = 1, BTW, is not good, should be 8 for now.)

thinkloop commented 8 years ago

That worked, thanks!

evilaliv3 commented 8 years ago

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

dchest commented 8 years ago

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.

thinkloop commented 8 years ago

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 .