Bug 1980462

> 1. Proposed a title of this feature request.

Use yescrypt as default hashing method for shadow passwords

> 2. Why do you need this feature? (List the business requirements here)

By the time of this writing, sha256crypt and sha512crypt, as used commonly today for hashing passwords, remain unbroken, but have some flaws by design:

 - Both hashing methods effectively only use about 90 bits of salt, although the NIST-recommendation for salt length is >= 128 bits.
 - Long passwords can create a denial-of-service on the CPU.
 - Passive observation of execution times can predict password length.
 - No use of a cryptographic key derivation function (KDF).

In conclusion, we would like to have to a stronger hashing method for computing the entries in the UNIX shadow file by default. And why not Argon2?

 - yescrypt has a dependency not only on RAM, but also on fast on-die local memory, which provides bcrypt-like anti-GPU properties even at very low per-hash RAM sizes (where Argon2 might even lose to bcrypt in terms of GPU attack speed).
 - yescrypt currently has less low-level parallelism within processing of a block, yet allows for tuning it later, whereas Argon2 has a fixed and currently commonly excessive amount of such parallelism, which may be extracted to speed up e.g. GPU attacks through use of more computing resources per the same total memory size due to each hash computation's memory needs being split between 32 threads (yescrypt currently has four 16-byte lanes that can be processed in parallel within a 64-byte sub-block before running into a likely data dependency for the next sub-block, whereas Argon2 allows for parallel processing of eight 128-byte chunks within a 1 KiB block with only two synchronization points for the entire block, as well as of four 32-byte parts of the 128-byte chunks with only two more synchronization points for the entire 1 KiB block).
 - yescrypt's cryptographic security is provided by SHA-256, HMAC, and PBKDF2, which are NIST-approved and time-tested (the rest of yescrypt's processing, while most crucial for its offline attack resistance properties, provably does not affect its basic cryptographic hash properties), whereas Argon2 relies on the newer BLAKE2 (either choice is just fine for security, but use of approved algorithms may sometimes be required for compliance)

> 3. How does the presence/absence of this feature benefits/impacts your Business/project operation? If so, Kindly provide a justification regarding the benefits/impact which is important for filing.

We use RHEL in security sensitive environments, also in the public sector or for governmental institutions. And there we would like to have the maximum security whenever possible.

> 4. How would you like to achieve this? (List the functional requirements)

Implementation of https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow like for Fedora for RHEL 9.0 in the same way.

> 5. How quickly does this need to be resolved for you?

RHEL 9.0 GA

> 6. Are you able to assist in testing this functionality if implemented?

Yes.