New fastest portable hash: wyhash

51–52 of 52 posts

Re: New fastest portable hash: wyhash

#51

Post by ncmncm » Wed, Mar 13, 2019, 3:31 PM UTC

haberman wrote: post #45

stcredzero wrote: post #44

Earlier quoted context omitted.

I don't understand why these two performance measures would not track perfectly, since the CPUs should be running a constant number of cycles/second. x86 isn't RISC and not all operations take the same number of cycles. Also, the code might have different levels of possible parallelism and might impact the pipeline differently. Comp Sci education for the low level basics is often completely neglected nowadays. This s…

> x86 isn't RISC and not all operations take the same number of cycles. Yes but it doesn't say instructions per hash, it says cycles per hash. Unless some kind of frequency scaling is going on, the number of cycles per second should be very consistent. If bytes/hash is held constant and cycles/second is constant, then MiB/second and cycles/hash should be exact inverses. I don't understand why this is not the case in…

I wonder if the first number is sustained, pipelined rate for big values, and the second number is cycles for the first iteration, still assuming everything is in L1 cache.

Those would be the useful numbers.

Re: New fastest portable hash: wyhash

#52

Post by minitech » Fri, Mar 15, 2019, 9:22 PM UTC

rurban wrote: post #49

GoblinSlayer wrote: post #47

Earlier quoted context omitted.

He means the worst case scenario when the attacker knows the key. In which case it's trivial indeed.

As I explained there, getting the hash seed of a running process in a dynamic language is trivial. Every language has enough ropes to hang yourself and print the value from some known offset. And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing. From there you just brute force an attack even with an extremely slow hash like…

> And if not, there's still enough information from a typical bad hash table (95% of hash tables are bad) to get at the seed via ordering and timing.

Really? How’s that? The SipHash seed isn’t supposed to be recoverable from hashes – that would be a pretty significant break – and I don’t see what other route the hash table would have to the seed.

> Every language has enough ropes to hang yourself and print the value from some known offset.

You mean explicitly reading the seed out for an attacker? If we’re modifying the program to help, I figure while (true) {} is probably a simpler DoS.

Post reply on HN