Yep... that was roughly my starting approach. Current one I'm playing with uses multiple samples (chosen as a function of the initial hash and the previous samples), to ensure the attacker has to actually take the whole file... otherwise the attacker gets away w/ 10% of file & 100 hashes, they've got good odds that one of those hashes only needs the first bit of the file.
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 :)
(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).
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 :)