On Tue, Sep 23, 2014 at 07:00:23PM -0400, George Spelvin wrote: > It's worse than that. The dcache has an great hit rate, and you have to > force misses. But if you actually hit the disk a lot, that will dwarf > hashing performance into unmeasurability. > > So it requires a very cleverly designed benchmark to highlight it. Well, yes. That's why I suggested doing something with a RAM disk. Perhaps creating a huge number of zero length files, then unmounting the the file system and remounting it, and then deleting the huge number of zero length files. If that doesn't show an improvement, then it's unlikely any real world use case would likely show an improvement.... > By criterion 2, SipHash *is* significantly stronger: it's presented at > crypto conferences, been studied, and is widely used. > > halfmd4 a very ad-hoc primitive that I don't think anyone's looked at > seriously. > > It's not obviously terrible, and it's possible that halfmd4 is more work > to break, but we won't know until someone with cryptanalytic skill takes > a swing at it. The other thing to consider is what you get if you manage to crack the crypto, which is that you might be able to force the worst case performance, and possibly cause a directory creation to fail with an ENOENT if the huge number of hash collisions cause the two-level htree to overfill. Neither is going to get you a huge amount, so it this decreases the incentive for someone to spend a lot of effort trying to attack the system. I'm quite certain though that if there is some way such a failure could cause an Iranian nuclear centrifuge to fail catastrophically, our friends at Fort Meade would have absolutely no problems finding an attack. After all, they did for MD5. :-) Cheers, - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
