[RFC] Add argon2 backend.

[ferivoz]

argon2 is a password-hashing function that summarizes the state of the art in the design of memory-hard functions and can be used to hash passwords for credential storage, key derivation, or other applications.

See: https://github.com/P-H-C/phc-winner-argon2

The argon2_i hash requires libargon2, which is an optional dependency.

Compatible with output of argon2 executable.

[ferivoz]

Regarding the advices given in https://github.com/besser82/libxcrypt/issues/104:

• I have added libargon2 as an optional dependency. The library is added if argon2_i has been selected as a hash, which is selected by default.
• I have reviewed the NetBSD implementation. They are not compatible with the output of argon2 executable. They store the salt as plaintext. It just looks like it is encoded in some base64 form, but in reality it is put into the argon2 function call as it is. Mixing a plaintext salt and a base64 encoded hash looks wrong to me and makes it difficult to experiment.
• I had to add some base64 encoding with a A-Za-z0-9/+ alphabet because that is what the reference implementation uses. The code is taken from reference implementation and marked with appropriate copyright. Maybe you prefer to switch to the base64 encoding used in scrypt?

Things to consider:

• Tests are missing yet. I can copy and paste argon2 encoded output into my /etc/shadow and login though
• Only argon2_i is supported right now. Adding argon2_d and argon2_id is trivial. I decided to not do it right now so I can integrate feedback much faster and add the missing functions when everything is settled.

I would love to get some feedback on this. You are free to edit my branch or add comments and let me know what you think!

[zackw]

Github isn't letting me add this to the specific code comment thread where it's relevant:

I think the inadequate M4 quotation in configure.ac is why all the Travis builds bombed out with weird shell errors.

Come to think of it, this PR should adjust the Travis configuration so we have libargon2 available at build time in most of the configurations. There should be one configuration that exercises the "no libargon2 at build time" code paths, but we already have so many Travis variant builds that I'd recommend piggybacking that on an existing variant rather than adding a new one.

[ferivoz]

I extended the pull request to contain Argon2id, Argon2i, and Argon2d. Argon2id is used by NetBSD as $argon2id$ and marked with NETBSD in hashes.conf. The NetBSD version is not compatible with argon2 output, regardless of specific hash.

I have to fix the Codacy findings. Therefore the pull request is WIP for now.

Thank you for your valuable feedback @zackw!

[ferivoz]

I have checked the reports but I do not know if I have to fix them or not. I think the argon2 code handles strings just like the other crypt files, e.g. bcrypt. In crypt-bcrypt.c, the size argument for setting is actually ignored.

Do you have an advice about it or do you think as well that these findings can or should be ignored?

[besser82]

Here is an overview of what got changed by this pull request:

Issues
======
+ Solved 1
- Added 5
           

See the complete overview on Codacy

[ferivoz]

Hi, I hope it is okay to ask for feedback again. Are there any news on this subject?

[eleius]

Hi, I hope it is okay to ask for feedback again. Are there any news on this subject?

I wanted to ask the same but... no activity in 2 years? :-/

[jonas-w]

https://github.com/besser82/libxcrypt/pull/150

[solardiz]

@eleius Given the timing of your comment, I guess it's related to Arch Linux's decision to switch to yescrypt - https://archlinux.org/news/changes-to-default-password-hashing-algorithm-and-umask-settings/ - where among other things they wrote "Although the winner of the Password Hashing Competition has been argon2, this even more resilient algorithm is not yet available in libxcrypt (attempt one, attempt two)."

Disclaimer: I've designed yescrypt, so obviously I am biased. I also was on PHC's panel (obviously not voting for my own entry), so I have studied all entries at least to some extent (and Argon2 pretty well, with both yescrypt and Argon2 influencing the final PHC versions of each other).

I think calling Argon2 an "even more resilient algorithm" is wrong. For practical purposes, I think it is not - on the contrary, yescrypt is likely more resilient. We give a comparison of yescrypt vs. Argon2 on the yescrypt homepage and in documentation, including in terms of attack resilience.

There were multiple criteria in the competition, with attack resilience being only one of them. Another was simplicity. Argon2 is simpler than yescrypt, and I accept that complexity is a drawback of yescrypt.

I have quite a backlog of tasks related to both yescrypt and Argon2. I maintain the upstream implementation of yescrypt and have some things to improve in there. I also co-maintain John the Ripper password cracker, where I think we'll want to have similarly optimized implementations of both, on both CPU and GPU, to allow for better comparison. It's non-trivial to optimize these things for GPUs well. So in terms of my own time, these tasks I just mentioned are a higher priority than helping get Argon2 into libxcrypt. I think it eventually should be in libxcrypt, at least for compatibility with other systems that use Argon2. However, I think ideally the related JtR work (or/and similar in hashcat) would be completed first, so that people (and even more importantly distros' defaults) would not be switching from yescrypt to Argon2 based on the "even more resilient" likely misconception. ;-)

As to eventual implementation of Argon2 support in here, I think it could be best to have parts of the upstream Argon2 tree https://github.com/P-H-C/phc-winner-argon2 merged into libxcrypt in a subdirectory and occasionally sync'ed to upstream, in the same way it's currently being done for yescrypt, instead of having a dependency on an external project.

[dvzrv]

I think calling Argon2 an "even more resilient algorithm" is wrong.

As this seems to lead to confusion/ skewed expectations, I have adjusted the wording in the mentioned news item. @solardiz thanks for reaching out via email and pointing it out!

[solardiz]

I think ideally the related JtR work (or/and similar in hashcat) would be completed first, so that people (and even more importantly distros' defaults) would not be switching from yescrypt to Argon2 based on the "even more resilient" likely misconception. ;-)

We've since got Argon2 supported on GPUs via OpenCL in John the Ripper bleeding-jumbo, here's an example of it in use on a hash with moderately high cost settings (above libxcrypt's current defaults for yescrypt): https://www.openwall.com/lists/john-users/2024/01/23/4 The break-even point for CPU vs. GPU for Argon2 appears to be at 100 to 200+ MB per hash (depending on which CPUs vs. which GPUs we consider comparable), which is much higher than libxcrypt's current default of 16 MiB for yescrypt. To test at 16 MiB, running against $argon2d$v=19$m=16384,t=3,p=1$c2hvcnRfc2FsdA$TLSTPihIo+5F67Y1vJdfWdB9 (note the t=3, which is 2.25 times more iterations over data than we currently use with yescrypt by default), I got 1742 c/s on GTX 1080 (before it fully heat up, so turbo speed, would reduce somewhat) vs. 438 c/s on 2x E5-2670 + 8x DDR3-1600 (pretty old hardware, I know). So ~4x speedup for a 180W, 2016 gaming GPU vs. 2x 115W = 230W 2012 server CPUs. Just sharing the data points we have so far. Edit: detail for these benchmarks is at https://github.com/openwall/john/pull/5382#issuecomment-2023959910