Gentoo Archives: gentoo-dev

From: John Helmert III <ajak@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt
Date: Mon, 25 Jul 2022 19:34:42
Message-Id: Yt7wSr47urRm5r/w@gentoo.org
In Reply to: Re: [gentoo-dev] Switching default password hashes from sha512 to yescrypt by Joshua Kinard
1 On Mon, Jul 25, 2022 at 03:30:08PM -0400, Joshua Kinard wrote:
2 > On 7/25/2022 14:44, Sam James wrote:
3 > >
4 > >
5 > >> On 22 Jul 2022, at 20:10, Mikhail Koliada <zlogene@g.o> wrote:
6 > >>
7 > >> Hello!
8 > >>
9 > >> This idea has been fluctuating in my head for quite a while given that the migration had happened
10 > >> a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
11 > >> by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
12 > >> with the ‘passwd’ call (a news item will be required).
13 > >>
14 > >> What do you think?
15 > >>
16 > >> P.S. surely, I am only speaking about the local auth method based on shadow and also about the pam-based systems as the change is going
17 > >> to mainly impact the pam_unix.so calls in the pam’s stack.
18 > >> Pamless or the systems with an alternative auth methods is a different story.
19 > >>
20 > >> [0] - https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html
21 > >> [1] - https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow
22 > >
23 > > It's fine with me although I guess I'm a bit reluctant when the libxcrypt stuff is still biting
24 > > some users.
25 > >
26 > > My preference would be to wait a few more months, but I don't feel strongly about it,
27 > > and won't object if we want to move forward sooner.
28 > >
29 > > Overall though, it's a good idea, although I'd welcome Jason's input
30 > > on alternatives first. CC'd.
31 > >
32 > > Best,
33 > > sam
34 >
35 > "yescrypt" is an odd name for a hashing algorithm. I looked it up on
36 > Wikipedia, and it just redirects to the 2013 Password Hashing Competition
37 > (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa,
38 > and lyra2). The winner was argon2. So unless something has changed in the
39 > last nine years or there is more recent information, wouldn't it make more
40 > sense to go with the winner of such a competition (argon2) instead of a
41 > runner-up? I know marecki said Fedora was waiting for an official RFC for
42 > argon2, but the wait for that ended almost a year ago in Sept 2021 when
43 > RFC9106[2] was released.
44 >
45 > Some really quick looking around, I'm not finding any substantive
46 > discussions on why yescrypt is better than argon2. It so far seems that it
47 > just got implemented in libxcrypt sooner than argon2 did, so that's why
48 > there is this sudden push for it.
49 >
50 > E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend
51 > yescrypt instead. Anyway, it has to be implemented in libcrypt.", but
52 > provides no justification for why they recommend yescrypt. Since we're
53 > dealing with a fairly important function for system security, I kinda want
54 > something with much more context that presents pros and cons for this
55 > algorithm over others, especially argon2.
56 >
57 > That said, there does appear to be an open pull request on libxcrypt for
58 > argon2[4], so maybe that is something to follow to see where it goes?
59 >
60 > 1. https://en.wikipedia.org/wiki/Password_Hashing_Competition
61 > 2. https://datatracker.ietf.org/doc/html/rfc9106
62 > 3. https://github.com/linux-pam/linux-pam/issues/45
63 > 4. https://github.com/besser82/libxcrypt/pull/150
64 >
65 > tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because
66 > it seems popular. I would prefer something that's been thoroughly tested.
67 > The scant info I've found thus far, that points to argon2, not yescrypt.
68
69 There's justification for this in one of the references in zlogene's
70 original mail:
71
72 https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow#Detailed_Description
73
74 > --
75 > Joshua Kinard
76 > Gentoo/MIPS
77 > kumba@g.o
78 > rsa6144/5C63F4E3F5C6C943 2015-04-27
79 > 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
80 >
81 > "The past tempts us, the present confuses us, the future frightens us. And
82 > our lives slip away, moment by moment, lost in that vast, terrible in-between."
83 >
84 > --Emperor Turhan, Centauri Republic
85 >

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies