Hacker News Reader

Comment by marcusfrex | Hacker News Reader

>> Spamming the input with an array of whatever OpenSSL algorithms Ruby happens to make available, rather than using a memory hard KDF like scrypt, is a bad smell.

Sooner or later key-derivation schemes gets outdated and requires a better version as happened to bcrypt [1] and will happen to scrypt [2].

It is not "whatever OpenSSL provides" but just combining strong algorithms over to spread the "getting outdated" risks. Think like you are investing your money? Would you prefer betting on just one thing or spreading it over various different investment opportunities?

[1] http://www.unlimitednovelty.com/2012/03/dont-use-bcrypt.html [2] http://blog.ircmaxell.com/2014/03/why-i-dont-recommend-scryp...

View on HN

Not only did that not happen to bcrypt, but the whole point of bcrypt is that that doesn't happen: it's an adaptive hashing scheme, which means it comes with a dial you can turn to up the hardness as computers get faster.

I would be nervous about taking password storage advice from someone who thinks bcrypt "got outdated and requires a better version".

We had a Password Hashing Competition because people realized that password hashing and KDFs had become an important topic that hadn't received significant formal study. Similarly: we're having a CAESAR competition because people have recognized the importance of all-in-one authenticated encryption constructions. The existence of CAESAR, AEZ, NORX, &c doesn't mean that Poly1305-AES is "outdated and requires a better version".

Probably i should explain what i meant with "got outdated and requires a better version" sentence. It is a race and as stronger algorithms comes to life -and stronger attack methods invented against them-, others gets simply weaker and weaker just like happened to MD2 and then MD4 And then MD5.

Sorry for misunderstanding.

MD4 and MD5 didn't get easier and easier to crack due to cryptanalytic advances; it got easier to generate collisions. That's a serious problem for a cryptographic hash, but depending on the construction you're using, it might not have anything to do with MD5's suitability as a password hash. There's no password hash cracking tool I'm aware of that takes advantage of MD5's weaknesses.

So, no: this isn't happening with bcrypt.

What evidence do you have that your scheme is any more future proof than, say, Argon2? No, just using a bunch of different primitives is not going to guard against the kind of breaks found in bcrypt or scrypt, which aren't really breaks at all.

Forgiva is not a key-derivation algorithm itself to compare with Argon2 but a combination way for various hashing and encryption algorithms along PBKDF2 "depending on master-key". So it's as much future-proof as master-key generated algorithm sequence.

And in this case which methods would you offer and prefer for future-proofing with comparison to other KDFs?

I would use an analysed algorithm such as Argon2 and be done with it. If you're so worried about bcrypt, why do you use PBKDF2 which is no better?

Actually i am not worried about bcrypt. I just wanted to use more enterprise level approved KDF other than individual work.

But regarding criticizes probably there will be bcrypt, scrypt and argon2 implementations as options on the next release.

The article you quote in [1] is not a good article. See the comment by perseids.

Reply on news.ycombinator.com