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