I can do it, once its gets approved/included
On Thu, Jun 10, 2021 at 6:21 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, Jun 7, 2021 at 3:00 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
>
> https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow
>
> == Summary ==
> Make the yescrypt hashing method the default method used for new user
> passwords stored in <code>/etc/shadow</code>.
>
>
> == Owner ==
> * Name: [[User:besser82| Björn Esser]]
> * Email: besser82@xxxxxxxxxxxxxxxxx
>
>
> == Detailed Description ==
> yescrypt is a password-based key derivation function (KDF) and
> password hashing scheme. It builds upon Colin Percival's scrypt, and
> is based on NIST-approved primitives.
>
> Cryptographic security of yescrypt (collision resistance, preimage and
> second preimage resistance) is based on that
> of SHA-256, HMAC, and PBKDF2. Even a catastrophic failure of
> yescrypt’s computational layers to maintain entropy would not affect
> yescrypt’s cryptographic properties as long as SHA-256, HMAC, and
> PBKDF2 remain unbroken. That said, in case SHA-256 is ever broken,
> yescrypt’s additional processing is likely to neutralize the effect of
> any such break.
>
> 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 crytographic key derivation function (KDF).
>
> In conclusion we should move to a stronger hashing method for
> computing the entries in the UNIX shadow file. So 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)
>
> Also see [https://www.openwall.com/yescrypt/ yescrypt - scalable KDF
> and password hashing scheme], the
> [https://www.password-hashing.net/submissions/specs/yescrypt-v2.pdf
> PHC submission paper],
> [https://lists.openwall.net/phc-discussions/2018/03/13/10 PHC yescrypt
> vs. Argon2], and
> [https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978553 the
> discussion on the Debian bugtracker].
>
>
> == Feedback ==
> No feedback, yet.
>
>
> == Benefit to Fedora ==
> yescrypt is the default password hashing scheme on recent ALT Linux,
> Debian testing, and Kali Linux 2021.1+, so we should adopt it as the
> default, too. Also, it is already the recommended hashing method in
> the [https://docs.fedoraproject.org/en-US/fedora-coreos/authentication/#_using_password_authentication
> Fedora CoreOS documentation].
>
>
> == Scope ==
> * Proposal owners: Help with integration for yescrypt support in some
> packages. See Dependencies.
> * Other developers: Integrate yescrypt support in some packages. See
> Dependencies.
> * Release engineering: [https://pagure.io/releng/issue/10150 #10150]
> * Policies and guidelines: N/A (not needed for this Change)
> * Trademark approval: N/A (not needed for this Change)
> * Alignment with Objectives: N/A (not needed for this Change)
>
>
> == Upgrade/compatibility impact ==
> No impact, as password hashes, that have been computed using the
> former default sha512crypt, will continue to work.
>
>
> == How To Test ==
> * Existing installations: Change your user password and check whether
> the computed password hash in <code>/etc/shadow</code> starts with
> <code>$y$</code>, like <code>root:$y$j9T$JEFtZ/…</code>.
> * Fresh installations: Check whether the password hash(es) for the
> user(s) created by anaconda in <code>/etc/shadow</code> start(s) with
> <code>$y$</code>, like <code>root:$y$j9T$JEFtZ/…</code>.
>
> == User Experience ==
> No user visible changes, but they can rely on safer hashing for their
> user passwords.
>
>
> == Dependencies ==
> * anaconda: https://github.com/rhinstaller/anaconda/pull/3431
> * authselect: https://github.com/authselect/authselect/pull/253
> * libuser: WIP ongoing
> * shadow-utils: https://src.fedoraproject.org/rpms/shadow-utils/pull-request/10
>
> * pam: Is already capable to use yescrypt.
> * libxcrypt: Is already capable for computing yescrypt hashes.
>
> == Contingency Plan ==
> * Blocks release? Yes
>
> Partially revert the changes, that have been applied to anaconda,
> authselect and shadow-utils, and rebuild those packages.
>
>
> == Documentation ==
> Fedora now uses the yescrypt hashing method for new passwords. There
> are no visible changes nor impacts to the end-user. Users are
> recommended to change their existing passwords after upgrading.
>
>
> == Release Notes ==
> Fedora now uses the yescrypt hashing method for new passwords. There
> are no visible changes nor impacts to the end-user. Users are
> recommended to change their existing passwords after upgrading.
>
If this gets done (I hope it does!), someone needs to update the
Security Matrix page:
https://fedoraproject.org/wiki/Security_Features_Matrix
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
