> I'd again have to make sure to use constant-time comparisons of the different output
Why? What would this mean? You have a flow like this:
1. User sends "password".
2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done.
3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password.
But even in step 3, you don't need constant-time comparisons. What purpose would they serve?
Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH.
But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.
Perhaps I was thinking of verifying API tokens. But see, I made a mistake while reasoning about security code. Don't make me do that more often than necessary, one day it'll go wrong.
Why? What would this mean? You have a flow like this:
1. User sends "password".
2. Time-hard hash processes "password" into some hex value, HASHT. No comparison is done.
3. SHA2 processes HASHT into some other hex value, SHAHASH. You compare SHAHASH to the user's stored hashed password.
But even in step 3, you don't need constant-time comparisons. What purpose would they serve?
Assume the attacker knows your full hashing algorithm -- they can compute SHAHASH for any input password. (Maybe your salt is equal to the username, say.) That's enough to use a standard timing attack against early-abort comparison to learn the first byte (or other comparison unit) of SHAHASH.
But to learn the second byte, you need to provide a large number of hashes which all have the correct first byte. This can't be done. (It can, but you'll have to generate around 256 times as many hashes as you can use.) To learn the third byte, you need to provide a large number of hashes which all have the correct first two bytes. This is even more impossible. (In fact, you may recognize this problem as being the proof-of-work that Bitcoin requires.) The whole point of using a cryptographic hash in the first place is that we can't predict the outcome of a hash! Constant-time comparisons are something you need when you're comparing an attacker-controlled value to a secret value, but that never occurs here.