I've noticed that SHA-512 password hashing leaks some information about the password length. There's a weak correlation between password length and time to hash. It's roughly linear, but in steps of 64 or so, and also dependent on salt length. I suppose a little extra length results in one extra block of hash input for each round.
To avoid leaking even this small amount of information, we could pad the password to a constant length before hashing it. The padding could be a reproducible secure hash of the password, salt, and/or number of rounds.
Since hashing the long padded password would take longer per round, we could use fewer rounds. Thus, overall, the hashing operation would not take longer (except for a little time to generate the padding).
(Of course, with the padding being a function of the password, one could dispense with the password and simply hash the padding instead. That seems risky, though; entropy might somehow be lost in the process.)
Does anyone see a problem with this padding idea? Do any attacks come to mind?
Edit: this is for a working system, but the target environment makes
it difficult to use anything but Python and the standard library;
there's no compiler, and adding precompiled libraries is problematic.
crypt(3) is available, but better algorithms such as bcrypt,
scrypt, and PBKDF2 are not — at least, not easily.
The idea with the padding is to pad with a constant string, hash that with a small number of rounds, and use the output as the padding for the full number of rounds.