Still trying to play with it to see if I can make it harder to parallelize assuming attacker does get the file. But that gets into designing an entire password hash, not just a friendly wrapper, which is more than I'm prepare to chew on right now :)
Still trying to play with it to see if I can make it harder to parallelize assuming attacker does get the file. But that gets into designing an entire password hash, not just a friendly wrapper, which is more than I'm prepare to chew on right now :)
http://www.openwall.com/presentations/ZeroNights2012-New-In-...
https://medium.com/@TapLink/the-password-defense-league-c416...
(I'm not happy with how Jeremy re-purposed the words "blind hashing" to mean essentially the approach I had recommended as a better alternative to his original "blind hashing", which I criticized in the ZeroNights talk, but other than that I agree with what he wrote.)
To "make it harder to parallelize assuming attacker does get the file" (actually, to increase the cost per candidate password tested, not to make anything literally "hard to do"), I propose that "best of both worlds" approach (see my ZeroNights slides). And you're right, this means "designing an entire password hash, not just a friendly wrapper" (thus, different from Jeremy's work, and more similar to my work on yescrypt).
I.e. out = hash xor data[hash] xor data[hash xor data[hash]] ...
Alternative phrasing: out_n = data[hash xor out_(n-1)] xor out_(n-1), where out_1 = data[hash] xor hash
"Random" accesses throughout the file - not the easiest to run in parallel.
(That being said, I haven't checked to see if this is breakable)