Get rid of modulo division in Argon2

[solardiz]

See P-H-C/phc-winner-argon2#306

We need this for both CPU and OpenCL formats. For CPU, perhaps do it after #2738.

[solardiz]

Done for OpenCL via #5401, yet to do for CPU.

[solardiz]

We may implement this by merging @Sc00bz's P-H-C/phc-winner-argon2#306 or by implementing changes ourselves like I did in 2434e3f for argon2-opencl or f1f8158 for Armory. It is easy to get this wrong for corner cases, so reusing tested code or/and thorough retesting with different lane counts (powers of 2 and not) is desirable.

@Sc00bz Maybe you want to contribute a pull request? We'd likely be much quicker to merge it than upstream not doing so. ;-)

[magnumripper]

FWIW when running a port of the same (ref) Argon2 code on nvidia, these fixes consistently result in a 3% regression. Not sure why but binary size increases with 602 bytes.

[solardiz]

FWIW when running a port of the same (ref) Argon2 code on nvidia, these fixes consistently result in a 3% regression. Not sure why but binary size increases with 602 bytes.

Thanks for letting us know. That's another reason to actually test performance of these changes on CPU. And likely exclude the unneeded changes for % ARGON2_ADDRESSES_IN_BLOCK. cc: @Sc00bz

As to the related changes I actually got into our OpenCL kernel, I benchmarked those and ensured at least no regressions. Some other revisions I didn't commit did in fact cause performance regressions in some cases on some devices I tested.

[magnumripper]

exclude the unneeded changes for % ARGON2_ADDRESSES_IN_BLOCK

Just for curiosity I tried that now for the nvidia. Somehow this made the binary size even larger (with 34 bytes, now 636), and speed regression remained. That's a bit strange but optimizer's results can be strange (and impressing: I also tried manually optimizing away the zero_block completely and that ended up 100% same when compiled).

Edit: The regressions aren't so strange considering we're way out of registers on GPU.

[solardiz]

@magnumripper I assume you continue to experiment with your reference Argon2 based OpenCL kernel just to improve your own understanding, not as something you intend to get in here, since we already have much faster code, correct?

[magnumripper]

That is sort of correct, except I may "have to" use it at some point for some format (given costs are sane, so maybe wont happen). Alain's kernel is not precisely a plug and play thing like the shared algos we have. The very slow experimental ref code is - just include it and call it.

To use Alain's kernel for keepass, I would "have to" make it a standalone keepass-argon2-opencl, probably even in the same source file as argon2-opencl for sharing all host-side support code it has. The details of that quickly get very tricky and very ugly (I tried once so far, and scratched it).

Also, I think keepass cost settings for Argon2 might be excessive for most GPU's of today regardless of code. I tried a hash with similar cost with Argon2-opencl and it even crashed - I'll open a ticket for that. Maybe it tried to allocate more memory than available.

I will probably end up not supporting Argon2 at all in keepass-opencl, just KDBX4 using AES.