3 ms·

This is relevant: > But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, whic

by lvh 9y ago

This is relevant: > But, seriously: you can throw a dart at a wall to pick one of these. Technically, argon2 and scrypt are materially better than bcrypt, which is much better than PBKDF2. In practice, it mostly matters that you use a real secure password hash, and not as much which one you use. It’s not so much a strict order of preference as it is a preference, any preference, so as to still be recommending things. Argon2 and scrypt are too close to call.

piracykills 9y ago
I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?
- lvh 9y ago
  Argon2 and the PHC precipitated a lot of analysis that increased our confidence in scrypt, too. My point is that it doesn’t really matter, so optimize for availability. I like Argon2 for the stamp of approval, but dislike all the confusion around parameter selection and i-vs-d confusion. (I know argon2id exists.)
  - piracykills 9y ago
    Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a webapp. In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.
    - lvh 9y ago
      Re parameter selection, I’m referring to: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#section-4 https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#sectio... Specifically: > We recommend the following procedure to select the type and the parameters for practical use of Argon2. As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :) To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!

by lvh 9y ago

piracykills 9y ago

I'm under the impression Argon2 is at least marginally better than scrypt as it has heavily analyzed side channel mitigations and such. Is scrypt better in some other way?

lvh 9y ago
Argon2 and the PHC precipitated a lot of analysis that increased our confidence in scrypt, too. My point is that it doesn’t really matter, so optimize for availability. I like Argon2 for the stamp of approval, but dislike all the confusion around parameter selection and i-vs-d confusion. (I know argon2id exists.)
- piracykills 9y ago
  Doesn't scrypt suffer from much of the same parameter selection issues? I know I've had to choose some fairly obtuse values when using scrypt for login in a webapp. In fact, taking a quick look again I find Argon2's "memorySizeKB" and "iterations" make much more sense to me than scrypt's "CostFactor" and "BlockSizeFactor" parameters as it's a lot clearer what's being impacted. I agree with the i-vs-d confusion, but in most cases I think using argon2id as you mentioned should resolve the contention as is already the suggested default in the IETF draft.
  - lvh 9y ago
    Re parameter selection, I’m referring to: https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#section-4 https://tools.ietf.org/html/draft-irtf-cfrg-argon2-03#sectio... Specifically: > We recommend the following procedure to select the type and the parameters for practical use of Argon2. As opposed to just pick a profile, which, to be fair, the RFC also suggests :) So I guess that’s a fair point, it just feels like as with the i-vs-d thing there’s just more song and dance around it that I wish wasn’t there. The suggestion in the RFC vs published 3rd party recommendations (eg jjarmoc’s NNC reco) are also off by a factor of 100 or so? I’m happy to buy that that’s an unfair subjective impression, but when I was reviewing an argon2id python implementation last week I really just wanted to give people a function that just does “encrypt my damn password already”. Maybe that’s up to the implementation layers job, that’s fine - I did that for txscrypt too and I don’t remember where I got the magic numbers from :) To be clear in case someone else reads this out of context: I am not saying not to use Argon2id!