[solardiz]

"Hash upgrades" have been added with the just-published v1 of the yescrypt submission to PHC. There is not yet an implementation of an "upgrade this hash" function (also, hash encoding needs to be finalized, including encoding of the upgrade count parameter), but now it's a matter of writing this additional code outside of the actual password hashing code (already capable of computing possibly-upgraded hashes).

Unfortunately, with memory-hard schemes such upgrades involve an efficiency loss in terms of normalized area-time, and there's a tradeoff between granularity of upgrades and efficiency. For Catena (another PHC finalist that supports these), the time granularity is 2x to 3x, with efficiency down to 33.3%+ of non-upgraded hashes (after many upgrades). For yescrypt, it's 4x to 5x granularity and 60%+ efficiency, respectively. (I felt that 33.3%+ is just not good enough - in my opinion, it's usually better to postpone the upgrade until 60%+ can be achieved rather than upgrade early and prevent it from ever being achieved. The next easy step would be 77.7%+, but the granularity would be too high.)

At the same time, support for ROM access frequency tuning (and thus for ROM-on-SSD, as opposed to ROM-in-RAM) has been dropped from yescrypt for now. The rationale is that builtin ROM-on-SSD didn't make enough sense without also having a ROM-in-RAM (in use cases for the former, the latter would also be easily affordable, including complexity wise, and would provide significant extra defense), and supporting two ROMs at once would be further beyond the comfort level for complexity of a hashing scheme in PHC (yescrypt is already somewhat beyond the comfort level). Support for two ROMs along with access frequency tuning might be re-added in an extended revision of yescrypt for specialized use cases at a later time, but this will be outside of PHC.