Hi Gary, > On 3. Feb 2025, at 17:00, Gary Buhrmaster <gary.buhrmaster@xxxxxxxxx> wrote: > > I never bothered to follow all the details > of the issue, but is there not a problem > where libxcrypt is not FIPS compliant? The answer is “it’s complicated”. NIST doesn’t really specify rules for password hashing in the FIPS context, they only cover key derivation from passwords, where they still recommend the dated PBKDF2. Better alternatives in the presence of attackers with GPUs exist. libxcrypt contains a bunch of password hashing implementations that are composed only of primitives that NIST considers acceptable in FIPS, e.g., sha512crypt. However, there’s a simple way to get out of this problem, and that is by defining in your compliance documentation that password hashing is not used for security and that you treat the password hashes as if they were plaintext. From that point of view, all that libxcrypt is doing is essentially equivalent to a base64encode(), and FIPS doesn’t care (*). *) this is not legal advice, I am not a lawyer, do your own research -- Clemens Lang RHEL Crypto Team Red Hat -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
