4 ms·

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 samp

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 :)

TheLoneWolfling 12y ago
I'd just do pointer-chasing through the file, xored with the initial hash each time. 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)
solardiz 12y ago
You should take a look at: http://www.openwall.com/presentations/ZeroNights2012-New-In-Password-Hashing/ http://www.openwall.com/presentations/ZeroNights2012-New-In-... https://medium.com/@TapLink/the-password-defense-league-c416ceaedb33 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).

TheLoneWolfling 12y ago

I'd just do pointer-chasing through the file, xored with the initial hash each time. 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)

solardiz 12y ago

You should take a look at: http://www.openwall.com/presentations/ZeroNights2012-New-In-Password-Hashing/ http://www.openwall.com/presentations/ZeroNights2012-New-In-... https://medium.com/@TapLink/the-password-defense-league-c416ceaedb33 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).