Bug#978553: pam_unix should default to yescrypt
On Tue, 2021-02-02 at 19:08 -0500, Sam Hartman wrote: > > > > > > I don't have any objection to moving to Argon2 once it's available Would sound like a good plan. In that case it might not even be necessary to mention an intermediate switch to yescrypt in the release notes, if that was superseded anyway sooner or later. > Amusingly enough, Debian openssh does not actually use AES for > encryption these days. Well but the same argument (as favouring Argon2) counts there, too. "Popular" algos like ChaCha, Poly1305 and Curve25519 stuff also receive(d) considerable analysis. > non-NIST-based probably still as > fallout > from DRB plus a desire to have a wider crypto ecosystem. Well AES isn't DRB... ;-) ... it's still Rijndael, so wouldn't worry too much here. Cheers :-)
Bug#978553: pam_unix should default to yescrypt
> "Christoph" == Christoph Anton Mitterer writes: Christoph> Wouldn't it then be a better choice to wait for the Christoph> availability of argon2? Christoph> Not that'd I'd have any insight on whether yescrypt is Christoph> much worse, but Argon2 is simply the winner and will Christoph> probably receive the most scrutiny over the years. So it Christoph> would seem like the wisest long term choice - just like Christoph> most people use Rijndael/AES and not so much the other Christoph> AES finalists. No, what we had was not so good, and Yescrypt is reduced to a compelling security proof. I think the amount of analysis that various things are getting is a factor we can consider. I don't have any objection to moving to Argon2 once it's available, I just don't know today that it will be critical to do so. Amusingly enough, Debian openssh does not actually use AES for encryption these days. For a while AES really did have close to 100% of the responsible cipher market despite its side channel issues. These days, you'll still see Ipsec using AES, but the ssh community is more likely to prefer something non-NIST-based probably still as fallout from DRB plus a desire to have a wider crypto ecosystem.
Bug#978553: pam_unix should default to yescrypt
On Tue, 2021-02-02 at 17:05 -0500, Sam Hartman wrote: > > > > > > I don't know whether that's long-term plan or not. > yescrypt and argon2 seem to have similar security properties. > I'd need to dig more into the PHC report to figure out whether > there's > enough of an advantage to do another switch. > I mean yeah, if argon2 was an option today I probably would have > picked Wouldn't it then be a better choice to wait for the availability of argon2? Not that'd I'd have any insight on whether yescrypt is much worse, but Argon2 is simply the winner and will probably receive the most scrutiny over the years. So it would seem like the wisest long term choice - just like most people use Rijndael/AES and not so much the other AES finalists. Cheers, Chris.
Bug#978553: pam_unix should default to yescrypt
> "Christoph" == Christoph Anton Mitterer writes: Christoph> Hey. I'd guess that the long term plan is then to switch Christoph> to Argon2? Christoph> May I suggest in advance that this is then added to Christoph> NEWS.Debian with the hint that people might perhaps want Christoph> to re-set their passwords? I don't know whether that's long-term plan or not. yescrypt and argon2 seem to have similar security properties. I'd need to dig more into the PHC report to figure out whether there's enough of an advantage to do another switch. I mean yeah, if argon2 was an option today I probably would have picked it, because I'm kind of a fan of security standards given my background:-) I actually think release notes may be better than news.debian. There are cases where news.debian entries get displayed to people on upgrade, and for a package like pam that everyone has installed, that seems like more of a big deal than is justified by this. I'll go file a bug against release-notes. --Sam
Bug#978553: pam_unix should default to yescrypt
Hey. I'd guess that the long term plan is then to switch to Argon2? May I suggest in advance that this is then added to NEWS.Debian with the hint that people might perhaps want to re-set their passwords? Cheers, Chris
Bug#978553: pam_unix should default to yescrypt
On Jan 03, Sam Hartman wrote: > I don't know what the sha512 option we're using as a default does, but I > suspect yescrypt is probably an improvement. Sorry, i'm too lazy today > to go look up what sha512 actually means. (I mean if it actually means > hash the password with sha512 with no salt, then that's so brain dead as > to not be plausible. I'm guessing it's some salted sha2-512-based KDF). Yes, it's salted, but the default configuration does not use near enough rounds to be robust nowadays. Yescrypt and Argon2 are a huge improvement over plain hashing because they are also memory-hard so that they cannot be cheaply implemented in ASICs. Argon2 may be added to libcrypt later this year (https://github.com/besser82/libxcrypt/pull/113), but it will be too late for the next Debian release and its main selling point is "winner of the PHC competition", so nobody is in a hurry to adopt it anyway. -- ciao, Marco signature.asc Description: PGP signature
Bug#978553: pam_unix should default to yescrypt
> "Marco" == Marco d'Itri writes: Marco> On Jan 02, Steve Langasek wrote: >> So, can you provide more rationale why you think this should be >> the default? Marco> Because yescrypt is the best password hashing algorithm Marco> available in libxcrypt and its default. Steve, Take a look at https://www.password-hashing.net/ for what appears to be a credible peer-reviewed process to look at password KDFs. I know some of the names on their review panel, and trust those people to have run a reasonable process. I have not read their report nor the academic papers. Note that yescrypt is *not* their recommended password hashing function, but it did receive an honorable mention. However, the winner is not supported by pam_unix https://github.com/linux-pam/linux-pam/issues/45 presumably because it is not supported by libxcrypt. Based on the following information I think yescrypt would be fine to enable: * PHC's honorable mention. I assume the security is good enough or they would not have included it. * Yescrypt's claim that it's security is dependent on SHA-256 and PBKDF2 (from their website). I have not independently verified this claim. I don't know what the sha512 option we're using as a default does, but I suspect yescrypt is probably an improvement. Sorry, i'm too lazy today to go look up what sha512 actually means. (I mean if it actually means hash the password with sha512 with no salt, then that's so brain dead as to not be plausible. I'm guessing it's some salted sha2-512-based KDF). signature.asc Description: PGP signature
Bug#978553: pam_unix should default to yescrypt
On Jan 02, Steve Langasek wrote: > So, can you provide more rationale why you think this should be the default? Because yescrypt is the best password hashing algorithm available in libxcrypt and its default. https://www.openwall.com/yescrypt/ explains its design tradeoffs. -- ciao, Marco signature.asc Description: PGP signature
Bug#978553: pam_unix should default to yescrypt
Control: tags -1 moreinfo On Mon, Dec 28, 2020 at 03:56:10PM +0100, Marco d'Itri wrote: > Package: libpam-modules > Version: 1.4.0-1 > Severity: normal > Now that a newer release has been packaged, "sha512" in > /etc/pam.d/common-password should be replaced by "yescrypt". My immediate reaction to being asked to change the default hash algorithm to one that I've never heard of is "hell no". So, can you provide more rationale why you think this should be the default? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Bug#978553: pam_unix should default to yescrypt
Package: libpam-modules Version: 1.4.0-1 Severity: normal Now that a newer release has been packaged, "sha512" in /etc/pam.d/common-password should be replaced by "yescrypt". -- ciao, Marco signature.asc Description: PGP signature
