Exposing PBKDF2 hashing algorithm for key generation, or just upgrading it
Danlock opened this issue · comments
I was glancing through Iron and I noticed that there was a slight mismatch between the minimum password length and the key derivation method, namely the SHA-1 hashing algorithm used inside PBKDF2.
This post explains it pretty concisely I think (https://www.chosenplaintext.ca/2015/10/08/pbkdf2-design-flaw.html).
The TL:DR is that by using a password longer than the 20 bytes that SHA-1 outputs, pbkdf2 is doing twice the amount of iterations for little, if no benefit.
All I am proposing is to change the digest option used in pbkdf2 in the generateKey() function to sha256 at least, to use all 32 bytes meaningfully.
I realize this would break existing implementations, so exposing it as an option would also be fine. I'm willing to write a pull request to do so, just wanted to put my thoughts out there first so someone else could point out any flaws.
Also this is just a question, but why we are using PBKDF2 at all? Is there a need for multiple passes for this use case? As long as we are applying a salt shouldn't just HMAC-SHA be fine?
I'm fine with an option to use SHA256.
Overall, this protocol is designed based on best practices and is written to protect users against their own mistakes when configuring it. Yes, you can do this with less work but that also means more exposure of bad config and user errors. It's working well so I am not inclined to change it. If you can show either potential exploit or meaningful reduction of cpu, it would be a lot more appealing change.
Closing due to lack of activity.
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.