4 ms·

> Pre-hash the input to bcrypt by passing it through SHA512. Makes bcrypt now grow in the exact same way as shacrypt. The pre-hash is only applied once, so the

• peeters 8y ago
  Edit: I stand corrected, the summary in the link below didn't agree with the more detailed steps it went into below. While the hash is used as the input to the next round, it is (for reasons beyond my understanding) repeated if necessary to match the length of the original password. But it still seems like if you're prehashing in both cases the performance issue goes away. Is that true? I thought shacrypt stretching worked by passing the output of a round of hashing as the input to the next round of hashing, so it would go from 4096 bytes to 64 bytes (e.g.) after the first round. That's how it's explained here: https://www.vidarholen.net/contents/blog/?p=33 https://www.vidarholen.net/contents/blog/?p=33. I'd love to be proven wrong. So it seems shacrypt and bcrypt would be equivalent. Do the expensive work from 4096 to <72 once, then subsequent rounds are all on the same size of input. I think my point stands, this is comparing apples and oranges unless you pre-hash the input to bcrypt and include that in the benchmark.