Additional Hash Function: scrypt

[ericelliott]

Additional Hash Function: scrypt

[ericelliott]

I'm open to the idea, but I have a couple of serious concerns:

1. Scrypt is a memory-hard alternative to PBKDF2 which could easily open up an out-of-memory attack vector if it's used on web servers, as credential is intended to be used.
2. Scrypt also appears to be the subject of far less academic research, which in the security world means that there is a greater chance of unknown vulnerabilities and undiscovered exploits.

[chrisspiegl]

I have to admit that I am not a security expert. Just wanted to give the idea since I read a little about it in Twitter discussions and Marco Arment choosing scrypt in favor of PBKDF2.

@dilvie your reasons seam very reasonable. That is why I really like your library!

[ericelliott]

Yeah, I took a close look at both scrypt and bcrypt to see if I should include support by default, but I was unable to find implementations with broad use and rigorous tests, and neither algorithm is as well researched as PBKDF2. I want to make it dead simple for developers to make a relatively secure choice. Sometimes that means we should make the most trustworthy choice the only choice... at least until more support surfaces for alternatives.

[brianmhunt]

For ease of reference, here is the seminal OpenBSD paper on bcrypt:

http://www.openbsd.org/papers/bcrypt-paper.pdf

[ericelliott]

According to OWASP, PBKDF2 is the only algorithm that qualifies for FIPS certification.

I think that rules the others out for now. I don't want to complicate matters by making people choose if the only available choices are less secure.

[brianmhunt]

While PBKDF2 may be the only algorithm qualifying for FIPS certification, I am personally wary of hanging any hat on FIPS as a measure of security, per se.

To quote Ted Unangst's post The future (or lack thereof) of LibreSSL’s FIPS Object Module:

[FIPS is] widely recognized as a worthless checkbox.
...
Note that FIPS mode isn’t just worthless, it’s actively harmful. It creates perverse incentives that lead to a toxic development process where necessary work doesn’t happen and unnecessary work does.

Which is not to say that FIPS compliance is not valuable - just that the value is orthogonal (and some argue detrimental) to security.

One take-away from this might be to make sure the API is extensible, to support bcrypt or scrypt or another algorithm as a plugin, without having to modify the credential code.

Just a thought. :)

Cheers

[ericelliott]

Which is not to say that FIPS compliance is not valuable - just that the value is orthogonal (and some argue detrimental) to security.

Noted. I agree with that view, but in this case, the FIPS requirement does reflect the consensus of the security community as far as I'm aware. PBKDF2 is very battle hardened and well researched, and OWASP specifically ranked those recommendations.

One take-away from this might be to make sure the API is extensible, to support bcrypt or scrypt or another algorithm as a plugin, without having to modify the credential code.

That would be ideal. Is this even possible? They don't all take the same set of parameters. Would we need to expose a lower level API for algorithms? You may notice if you read the source that I did have swapping algorithms in mind when I wrote it. =)

I just haven't taken the time to try to do it, yet. I'm definitely open to a pull request if it doesn't weaken the security. You really have to be careful about opening up new attack vectors when you increase the surface area of the API...

[brianmhunt]

Just another quick link to crypto.SO for ease-of-reference:

Bcrypt has the best kind of repute that can be achieved for a cryptographic algorithm: it has been around for quite some time, used quite widely, "attracted attention", and yet remains unbroken to date.

Bcrypt is regarded as being more costly to attack because it is less susceptible to GPU & FPGA optimizations (which speed up SHA-* computations by orders of magnitude, and these are the basis for PBKDF2). There are no equivalent hardware based optimizations for Blowfish, which serves as the basis for bcrypt. Blowfish however, unlike SHA-256, has never been evaluated by NIST.

[ericelliott]

👍

I am aware of GPU and FPGA attacks on PBKDF2, however, if memory serves, Blowfish can be accelerated by large memory arrays which can also be built for less than $2k with current hardware. Am I mistaken in that belief?

[ericelliott]

A little more info on hardware acceleration for cryptography. Looks like essentially, hardware reduction of the need for DMA transfers can dramatically improve blowfish attack speeds.

[brianmhunt]

Great question. I recalled Blowfish being faster with larger memory space, but I do not know - but would love to see - some comparisons. I have a suspicion that Blowfish is still substantially slower/more expensive than SHA-*, but it would be great to see hard numbers.

[ericelliott]

Agreed. =)