This message is in MIME format. Since your mail reader does not understandthis format, some or all of this message may not be legible.
</style></head><body lang=en-RU link="#0563C1" vlink="#954F72" style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span lang=EN-US>Hello!<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><pclass=MsoNormal><span lang=EN-US>This idea has been fluctuating in my head for quite a while given that the migration had happened<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>a while ago [0] and some other major distributions have already
Hello!
This idea has been fluctuating in my head for quite a while given that the migration had happened
a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
with the ‘passwd’ call (a news item will be required).
What do you think?
This idea has been fluctuating in my head for quite a while given
that the migration had happened a while ago [0] and some other
major distributions have already adopted yescrypt as their default algo
by now [1].
On 2022-07-25 15:35, Peter Stuge wrote:
Please only do that based on proven merit and nothing else.
https://pthree.org/2018/05/23/do-not-use-sha256crypt-sha512crypt-theyre-dangerous/
, https://www.password-hashing.net/ , the fact we still us the default
number of rounds (i.e. 5000) with SHA512 which is *ridiculously* weak
for modern hardware, lack of Argon2 support in libxcrypt for the time
being due to upstream having decided to wait for an official RFC. You
can probably find more yourself if you look.
On 22 Jul 2022, at 20:10, Mikhail Koliada <[email protected]> wrote:
Hello!
This idea has been fluctuating in my head for quite a while given that the migration had happened
a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
with the ‘passwd’ call (a news item will be required).
What do you think?
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
to mainly impact the pam_unix.so calls in the pam’s stack.
Pamless or the systems with an alternative auth methods is a different story.
[0] - https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html
[1] - https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow
Some really quick looking around, I'm not finding any substantive
discussions on why yescrypt is better than argon2. It so far seems that it just got implemented in libxcrypt sooner than argon2 did, so that's why
there is this sudden push for it.
E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend yescrypt instead. Anyway, it has to be implemented in libcrypt.", but provides no justification for why they recommend yescrypt. Since we're dealing with a fairly important function for system security, I kinda want something with much more context that presents pros and cons for this algorithm over others, especially argon2.
On Mon, Jul 25, 2022 at 03:30:08PM -0400, Joshua Kinard wrote:
"yescrypt" is an odd name for a hashing algorithm. I looked it up on
Wikipedia, and it just redirects to the 2013 Password Hashing Competition
(PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa,
and lyra2). The winner was argon2. So unless something has changed in the >> last nine years or there is more recent information, wouldn't it make more >> sense to go with the winner of such a competition (argon2) instead of a
runner-up? I know marecki said Fedora was waiting for an official RFC for >> argon2, but the wait for that ended almost a year ago in Sept 2021 when
RFC9106[2] was released.
Some really quick looking around, I'm not finding any substantive
discussions on why yescrypt is better than argon2. It so far seems that it >> just got implemented in libxcrypt sooner than argon2 did, so that's why
there is this sudden push for it.
E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend >> yescrypt instead. Anyway, it has to be implemented in libcrypt.", but
provides no justification for why they recommend yescrypt. Since we're
dealing with a fairly important function for system security, I kinda want >> something with much more context that presents pros and cons for this
algorithm over others, especially argon2.
That said, there does appear to be an open pull request on libxcrypt for
argon2[4], so maybe that is something to follow to see where it goes?
1. https://en.wikipedia.org/wiki/Password_Hashing_Competition
2. https://datatracker.ietf.org/doc/html/rfc9106
3. https://github.com/linux-pam/linux-pam/issues/45
4. https://github.com/besser82/libxcrypt/pull/150
tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because >> it seems popular. I would prefer something that's been thoroughly tested. >> The scant info I've found thus far, that points to argon2, not yescrypt.
There's justification for this in one of the references in zlogene's
original mail:
https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow#Detailed_Description
On 7/25/2022 14:44, Sam James wrote:
On 22 Jul 2022, at 20:10, Mikhail Koliada <[email protected]> wrote:
Hello!
This idea has been fluctuating in my head for quite a while given that the migration had happened
a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
with the ‘passwd’ call (a news item will be required).
What do you think?
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
to mainly impact the pam_unix.so calls in the pam’s stack.
Pamless or the systems with an alternative auth methods is a different story.
[0] - https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html
[1] - https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow
It's fine with me although I guess I'm a bit reluctant when the libxcrypt stuff is still biting
some users.
My preference would be to wait a few more months, but I don't feel strongly about it,
and won't object if we want to move forward sooner.
Overall though, it's a good idea, although I'd welcome Jason's input
on alternatives first. CC'd.
Best,
sam
"yescrypt" is an odd name for a hashing algorithm. I looked it up on Wikipedia, and it just redirects to the 2013 Password Hashing Competition (PHC)[1], in which yescrypt was just a runner-up (along w/ catena, makwa,
and lyra2). The winner was argon2. So unless something has changed in the last nine years or there is more recent information, wouldn't it make more sense to go with the winner of such a competition (argon2) instead of a runner-up? I know marecki said Fedora was waiting for an official RFC for argon2, but the wait for that ended almost a year ago in Sept 2021 when RFC9106[2] was released.
Some really quick looking around, I'm not finding any substantive
discussions on why yescrypt is better than argon2. It so far seems that it just got implemented in libxcrypt sooner than argon2 did, so that's why
there is this sudden push for it.
E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend yescrypt instead. Anyway, it has to be implemented in libcrypt.", but provides no justification for why they recommend yescrypt. Since we're dealing with a fairly important function for system security, I kinda want something with much more context that presents pros and cons for this algorithm over others, especially argon2.
That said, there does appear to be an open pull request on libxcrypt for argon2[4], so maybe that is something to follow to see where it goes?
1. https://en.wikipedia.org/wiki/Password_Hashing_Competition
2. https://datatracker.ietf.org/doc/html/rfc9106
3. https://github.com/linux-pam/linux-pam/issues/45
4. https://github.com/besser82/libxcrypt/pull/150
tl;dr, I'm just a bit uncomfortable adopting a new hashing algo just because it seems popular. I would prefer something that's been thoroughly tested. The scant info I've found thus far, that points to argon2, not yescrypt.
--
Joshua Kinard
Gentoo/MIPS
[email protected]
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
On 22 Jul 2022, at 20:10, Mikhail Koliada <[email protected]> wrote:
Hello!
This idea has been fluctuating in my head for quite a while given that the migration had happened
a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
with the ‘passwd’ call (a news item will be required).
What do you think?
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
to mainly impact the pam_unix.so calls in the pam’s stack.
Pamless or the systems with an alternative auth methods is a different story.
[0] - https://www.gentoo.org/support/news-items/2021-10-18-libxcrypt-migration-stable.html
[1] - https://fedoraproject.org/wiki/Changes/yescrypt_as_default_hashing_method_for_shadow
It's fine with me although I guess I'm a bit reluctant when the libxcrypt stuff is still biting
some users.
My preference would be to wait a few more months, but I don't feel strongly about it,
and won't object if we want to move forward sooner.
Overall though, it's a good idea, although I'd welcome Jason's input
on alternatives first. CC'd.
Best,
sam
On 7/25/2022 15:30, Joshua Kinard wrote:
[snip]
Some really quick looking around, I'm not finding any substantive discussions on why yescrypt is better than argon2. It so far seems that it just got implemented in libxcrypt sooner than argon2 did, so that's why there is this sudden push for it.
E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend yescrypt instead. Anyway, it has to be implemented in libcrypt.", but provides no justification for why they recommend yescrypt. Since we're dealing with a fairly important function for system security, I kinda want something with much more context that presents pros and cons for this algorithm over others, especially argon2.
So there is this question and three answers on Crypto StackExchange. It is about five years-old, but it's got more detail on why argon2 won the PHC instead of one of the other contenders. It is still subjective information, but more thorough: https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc
There's some more info if one continues to deep-dive on CSE, but I am noticing a lot of the info is several years old. Some more recent things make references to a newer algo called Balloon, but that seems to be going off into side-tangents.
Anyways, I guess I am just being paranoid. If a change to hashing algos is made, it should be based on facts and not popularity contests or feelings.
--
Joshua Kinard
Gentoo/MIPS
[email protected]
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943
"The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
On Mon, Jul 25, 2022 at 03:59:59PM -0400, Joshua Kinard wrote:
On 7/25/2022 15:30, Joshua Kinard wrote:
[snip]
Some really quick looking around, I'm not finding any substantive
discussions on why yescrypt is better than argon2. It so far seems that it >>> just got implemented in libxcrypt sooner than argon2 did, so that's why
there is this sudden push for it.
E.g., on Issue #45 in linux-pam[3], user ldv-alt just states "I'd recommend >>> yescrypt instead. Anyway, it has to be implemented in libcrypt.", but
provides no justification for why they recommend yescrypt. Since we're
dealing with a fairly important function for system security, I kinda want >>> something with much more context that presents pros and cons for this
algorithm over others, especially argon2.
So there is this question and three answers on Crypto StackExchange. It is >> about five years-old, but it's got more detail on why argon2 won the PHC
instead of one of the other contenders. It is still subjective information, >> but more thorough:
https://crypto.stackexchange.com/questions/48933/why-did-argon2-win-the-phc >>
There's some more info if one continues to deep-dive on CSE, but I am
noticing a lot of the info is several years old. Some more recent things
make references to a newer algo called Balloon, but that seems to be going >> off into side-tangents.
Anyways, I guess I am just being paranoid. If a change to hashing algos is >> made, it should be based on facts and not popularity contests or feelings.
I'm not sure it's fair to suggest this change is based on "popularity contests or feelings". The facts were given in the original mail, just because one finds them unconvincing doesn't mean those facts aren't
real and convincing to others.
On Fri, Jul 22, 2022 at 3:10 PM Mikhail Koliada <[email protected]> wrote:
Hello!
This idea has been fluctuating in my head for quite a while given that the migration had happened
a while ago [0] and some other major distributions have already adopted yescrypt as their default algo
by now [1]. For us switching is as easy as changing the default use flag in pambase and rehashing the password
with the ‘passwd’ call (a news item will be required).
What do you think?
Seems like a reasonable idea to me.
What do you think?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 161:26:23 |
| Calls: | 12,094 |
| Calls today: | 2 |
| Files: | 15,000 |
| Messages: | 6,517,775 |