randomize hash values per process

[StefanKarpinski]

Other languages randomize their hash values per process to protect against DOS attacks on hash tables by intentionally causing hash table collisions. This also forces users not to rely on accidental dictionary ordering in their code. Even in languages where dictionaries are ordered, it's a good DOS prevention measure to randomize the hashing per process: the change becomes invisible (because of ordering), but since attackers can't predict hash collisions, they can't force them. Regardless of whether we go with ordered dicts or not, we may want to do this.

[exaexa]

+1 for this.

To be honest this is also tremendously useful for catching bugs where people depend on unreliable ordering of the stuff in Dict/Set/unique/... . Technically I'd even consider randomizing the order to be a good practice (there's no performance hit and problems get exposed sooner than later).

(Related thread in the slack: https://julialang.slack.com/archives/C6A044SQH/p1674933909186449 -- as a user you could currently try to replace hashindex in Base to do this functionality yourself; unfortunately that crashes all julia versions I tried (1.8 provided most colorful results).)

[exaexa]

(btw, I can probably write a patch; any hint on the randomness source would be very welcome though. PID+localtime could work?)

[gbaraldi]

It depends on how fancy you want to get here. If rand() is already defined at that point then it's a good option, otherwise ccall into jl_rand or if you want to get fancy. Which you might, uv_rand

[rfourquet]

There is also Libc.rand.

[PallHaraldsson]

We should likely do this since:
https://ocert.org/advisories/ocert-2011-003.html

The attacker, using specially crafted HTTP requests, can lead to a 100% of CPU usage which can last up to several hours depending on the targeted application and server performance, the amplification effect is considerable and requires little bandwidth and time on the attacker side.

https://docs.python.org/3/using/cmdline.html

Python randomizes and e.g. this turns it off:

PYTHONHASHSEED=1 python3

Python has -R to control this (to enable, but now on by default, so I'm not sure this is ever used, except to disable the env var). It seems like we might want a way to disable for debugging reasons.

I noticed Python randomizes hashes for strings too. So likely all hashes are just randomized. I'm not strictly sure that's needed, but is simplest implementation. Would non-randomzised hashes for e.g. strings and integers be any risk on its own, or only when used in a Dict?