4 ms·
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
by 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.