-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Investigate possibility of re-enabling threads? #52
Comments
Hi! Here's the time I get, while results are absolutely the same:
I need to investigate how threading works in argon2 and on which parameters we can benefit from it. I tried increasing the number of iterations, but it behaves the same way, that's very strange. |
More iterations, less memory, Argon2i, Iterations=10000, Memory=1024 KiB:
I'm not sure I get the point of having threading support in Argon2 🤔 when do we need it? |
If you're interested, I've just built a version with SIMD, check it out, it's 2x faster: https://antelle.net/argon2-browser/ Just noticed how the native version behaves without threading support:
And with threading support:
|
Okay I see, it reports CPU time, not wallclock: P-H-C/phc-winner-argon2#204. |
Threaded version is actually quite easy to build, however it doesn't give any improvement while the file size grows significantly (2x wasm and 4x js), you can also try doing it by adding
At the moment I don't think we should release it, but I'll keep an eye on its progress. |
I confirm, in my implementation I had tried too and the results are very closed even with more threads. I do think this is completely wanted. Argon2 is designed to limit hardware brute-forcing. From my understanding, the parallelism is here to enforce the hardware to use more resources, even if this is not speeding up the process. So, activating the multi-threading is important in a way that you enforce someone trying to attack you to use more resources. |
@glihm it depends how calculations are made: either we set a predefined complexity and then threading support should make it faster (that's how I assume it works), or complexity grows with increasing parallelism (then single-threaded implementation would take more time for higher parallelism values). |
With the native implementation, increasing the amount of parallelism is intended to keep the time constant but increase complexity. It's very strange to me that using a single thread with a larger parallelism value would not incur a larger time penalty. Perhaps the threading isn't being utilised correctly (so it's always using one thread)? |
I will do some experiments and research on this topic. |
Is it stated anywhere in docs? I see that it's the opposite: increasing parallelism allows implementations to calculate the hash using several threads, then how they make use of this possibility it's up to them. For example, in WASM we're not using threads at all, so the performance remains constant. The native tool uses them with different degree of success. |
Found it in docs: So, it's like I describe it: it's number of chains that can be run. The complexity is exactly the same, however required work can be splitted. |
@TomMettam I've pushed my threading experiments to this branch, it contains a working example that can run up to 8 threads, you can play with it if you want. Compile it, break it, love it, hate it, let me know if you manage to get anything interesting out of it. I've also uploaded it here if you just want to run it in your browser and compare performance: https://share.antelle.net/argon2-threads/, spoiler: it's slow 🐌 (≈2x) and big 🥴 (≈+40k). |
I believe this is now resolved and we can close the issue. The branch is here, and I'll return to it once a year or if there's any news about threads in WASM. |
I realize this is not an active topic anymore, I just want to note that in my compiled test, the threaded version is significantly faster than the non-threaded version. On latest master branch, vs threaded branch on latest emscripten docker image and using Firefox I get ~10 seconds, vs ~2.5 seconds on parallelism = 16, iterations = 10, memory = 1GiB on a 4 core, 8 thread system. |
Any chance of re-enabling threads? @quexten how's testing been on your branch? Are you using it in any projects? |
Friendly bump. @antelle is this project still maintained? I noticed there haven't been any commits in a while but sometimes that's normal. |
Hello!
In issue #15 threads were disabled. My understanding is that this means that generating a hash with a parallelism value of > 1 becomes exponentially more expensive for the defender but cheaper for an attacker using a different library.
WebAssembly Threads are a lot more mature now, being enabled by default in Chrome since v74. Could the possibility of re-enabling threads be investigated?
The text was updated successfully, but these errors were encountered: