All modern password hashing schemes are deliberately designed to include a huge amount of "busy-work", to limit the speed with which an attacker would be able to conduct password hashing attempts. Further, a goal in newer schemes is to reduce the amount by which special-purpose hardware can be made more efficient than commodity hardware of similar cost. If a "unit of work" in each of several algorithms is defined as the amount of work that could be done per second per dollar of hardware that was optimized for that task, the goal is to maximize the number of work units that can be done in an acceptable timeframe using production hardware. Because commodity machines differ in how efficiently they can perform various operations, however, this would suggest that different algorithms would be optimal on different production machines. For example, while it's desirable for algorithms to be GPU-hostile if production machines won't have GPUs, on production platforms which can use a GPU it would be better to have a GPU-friendly busywork algorithm.
Given the password hashing algorithm:
hash = secureHash(password, salt)
Using one or more forms of busywork:
busyResult = busyWork(hash, params)
hash = secureHash(hash, busyResult, extraSalt)
If one assumes that secureHash has all the properties necessary for a secure hash, would overall security be reliant upon any cryptographic properties of the busyWork functions used beyond the fact that their outputs not be computable without performing a certain amount of work? If not, would it be reasonable to favor different kinds of busy-work on different production environments, if:
Each password record included a list of the forms of busy-work that were used to create it, along with the appropriate parameters.
Each production environment would be capable of performing all forms of busy work, even if not optimally efficiently.
In the event of hardware changes that would cause the current password algorithm to take longer than ideal, a user's stored password hash could be transparently updated to use the new algorithm on the user's next login (the user need not know this was taking place).
Trying to design a secure hashing algorithm for every different flavor of system which was optimized around that system's precise abilities would be difficult. If, however, the requirement was weaker, and it was only necessary to show that the busywork algorithm was close to the fastest means of producing a certain output on a given system, and that every different hash value fed into the algorithm would be likely to produce different outputs (not hard to do if the output could be much larger than the input), it would seem that producing algorithms optimized for different platforms would be much easier.
Main question: If the secureHash function is good, and the time required for at least some of the busy-work functions cannot be effectively reduced, would there be any way in which a poor busy-work function could compromise security, other than by taking time away from the better busy-work functions?