1

Both bcrypt and scrypt hashing algorithms are designed to increase the resources required during the computation. Hashing passwords with these algorithms can be beneficial as it makes the task of an offline attacker more difficult.

The time required to hash a password can be increased by increasing the number of iterations in bcrypt. The attacker then has to execute this iterations in sequential manner as there is no assumed shortcut.

The memory required to hash a password can be increased in scrypt. The attacker will therefore need a large amount of memory to mount parallel attacks.

As, I understand both these algorithm attempt to thwart the parallel attacks.

My question is can we make SHA-x or any exiting secure hash algorithm iterative and memory intensive, and achieve the same functionality as that of bcrypt and scrypt?

Curious
  • 1,452
  • 2
  • 14
  • 26

2 Answers2

3

Making a hash function "iterative" already exists; it is called PBKDF2. Bcrypt is still preferable because PBKDF2 can be thoroughly optimized on GPU.

Designing a good password hashing function is a difficult job; but yes, existing hash function are good building elements, so they are likely to be involved at some point. Indeed, look at scrypt: it starts and ends with a PBKDF2 invocation, hence a lot of hashing. But the memory hardness comes from what happens between these two hashing phases. It is not a matter of a simple assemblage of hash functions that would provide memory hardness; just like a car is not simply "wheels that go where you want": the wheels are essential, but there is more in a car than wheels.

Cryptographers are currently busy designing and analysing new password hashing functions that try to be better (in some way) than PBKDF2, bcrypt and scrypt. This is the Password Hashing Competition. Some of the candidates reuse existing hash functions (e.g. Catena), but, like scrypt, their nice "password hashing" properties (e.g. memory hardness) comes from the rest of the design.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
1

Your understanding of the reasons why one should use scrypt and bcrypt is correct.

Yes, you could, at least in theory, produce a new algorithm that requires time and memory, and it could incorporate an existing cryptographically secure hash function. You can increase time through iteration, and increase memory by requiring large numbers of prior values to be available to compute the next value. But why? As you point out, there are already functions that do this, designed by cryptographers, subjected to inspection by others, and that have withstood the test of time.

Trying to roll your own crypto is very dangerous. Your question tells why: "there is no assumed shortcut." It is not enough for an algorithm to be time and memory intensive; it must also be resistant to shortcut attacks. Shortcut attacks can be subtle and clever, and avoiding them, or even spotting the vulnerabilities is hard, especially in your own work, which you "know" is correct. You are far more likely to end up with what someone else has called "wacky hash functions" that turn out to have easy shortcuts.

If you want to design your own cryptographic algorithms, first get a Ph.D. in math with a concentration in crypto. The NSA will hire you when you've got that Ph.D. After that, spend ten years working on crypto at NSA and you might be qualified to develop new cryptographic algorithms.

Bob Brown
  • 5,293
  • 1
  • 19
  • 28