Has there been any consideration switching to some other hash implementation?

There has been a few in the past, e.g. [Feature#16851]

Admittedly, I'm not a hash expert nor a cryptographer. There doesn't seem to be any known vulnerabilities with XXH3 that I have found.

Well, the main concern is HashDOS, but looking at your branch, it seems you seed the hash function, so it's fine on that front.

The same benchmarks on an M4 Pro:

benchmark-driver ~/Downloads/hash_strings.yml -e "ruby-master::~/.rubies/ruby-master/bin/ruby" -e "ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby"<snip>Comparison:               tiny_hash_creation         ruby-xxhash:     12650.7 i/s          ruby-master:     11909.3 i/s - 1.06x  slower                med_hash_creation         ruby-xxhash:     13716.7 i/s          ruby-master:     12271.1 i/s - 1.12x  slower              large_hash_creation         ruby-xxhash:     11178.4 i/s          ruby-master:      7120.5 i/s - 1.57x  slower               huge_hash_creation         ruby-xxhash:       235.8 i/s          ruby-master:        43.8 i/s - 5.38x  slower

benchmark-driver ~/Downloads/json_parse.yml -e "ruby-master::~/.rubies/ruby-master/bin/ruby" -e "ruby-xxhash::~/.rubies/ruby-xxhash/bin/ruby    <snip>Comparison:                  parse_activitypub_json                ruby-xxhash:     16495.3 i/s                 ruby-master:     16192.3 i/s - 1.02x  slower                  parse_twitter_json_txt                ruby-xxhash:      1828.2 i/s                 ruby-master:      1774.9 i/s - 1.03x  slower             parse_citm_catalog_json_txt                ruby-xxhash:       881.7 i/s                 ruby-master:       844.5 i/s - 1.04x  slower                     parse_ohai_json_txt                ruby-xxhash:     18377.8 i/s                 ruby-master:     17193.5 i/s - 1.07x  slower

byroot (Jean Boussier) wrote in#note-2:

Well, the main concern is HashDOS, but looking at your branch, it seems you seed the hash function, so it's fine on that front.

I did note the HashDOS conversation onhttps://bugs.ruby-lang.org/issues/13017 so I used XXH3_64bits_withSecret as an attempt to mitigate HashDOS by using the default secret and seed.

Reading through the xxhash docs I thinkXXH3_64bits_withSecretandSeedmight even be faster but I have not tried it yet.

FWIW

• https://github.com/Nicoshev/rapidhash claims to be even faster and passes the SMHasher tests
• Since Rust 1.36 they switched from SipHash13 tohttps://github.com/rust-lang/hashbrown for hashmaps

bdewater (Bart de Water) wrote in#note-6:

FWIW

• https://github.com/Nicoshev/rapidhash claims to be even faster and passes the SMHasher tests
• Since Rust 1.36 they switched from SipHash13 tohttps://github.com/rust-lang/hashbrown for hashmaps

I can give rapidhash a try. It's based on wyHash which Go uses (at least sometimes):https://github.com/golang/go/blob/cbe153806e67a16e362a1cdbbf1741d4ce82e98a/src/runtime/hash64.go

rapidhash is (mostly) faster than xxh3 on my M1 Macbook Air. Thelarge_hash_creation has twice reported that xxhash is faster than rapidhash.

Note that rapidhash uses a single 64bit seed. xxh3 uses a 136 byte secret.

rapidhash branch

Hashing strings:

tiny_hash_creation      ruby-rapidhash:      9267.6 i/s          ruby-xxhash:      8970.8 i/s - 1.03x  slower         ruby-master:      8329.4 i/s - 1.11x  slower                med_hash_creation      ruby-rapidhash:      9276.3 i/s          ruby-xxhash:      9274.3 i/s - 1.00x  slower         ruby-master:      8097.3 i/s - 1.15x  slower              large_hash_creation         ruby-xxhash:      7758.0 i/s       ruby-rapidhash:      7597.1 i/s - 1.02x  slower         ruby-master:      4318.7 i/s - 1.80x  slower               huge_hash_creation      ruby-rapidhash:       187.1 i/s          ruby-xxhash:       165.4 i/s - 1.13x  slower         ruby-master:        25.1 i/s - 7.45x  slower

JSON Parsing:

Comparison:                  parse_activitypub_json             ruby-rapidhash:     11210.7 i/s                 ruby-xxhash:     11186.6 i/s - 1.00x  slower                ruby-master:     11146.3 i/s - 1.01x  slower                  parse_twitter_json_txt             ruby-rapidhash:      1199.5 i/s                 ruby-xxhash:      1186.2 i/s - 1.01x  slower                ruby-master:      1169.7 i/s - 1.03x  slower             parse_citm_catalog_json_txt                ruby-xxhash:       611.1 i/s              ruby-rapidhash:       609.1 i/s - 1.00x  slower                ruby-master:       595.1 i/s - 1.03x  slower                     parse_ohai_json_txt             ruby-rapidhash:     12557.8 i/s                 ruby-xxhash:     12365.8 i/s - 1.02x  slower                ruby-master:     10824.1 i/s - 1.16x  slower

On 1/12/26 3:10 PM, bdewater (Bart de Water) via ruby-core wrote:

Issue#21833 has been updated by bdewater (Bart de Water).

FWIW

• https://github.com/Nicoshev/rapidhash claims to be even faster and passes the SMHasher tests
• Since Rust 1.36 they switched from SipHash13 tohttps://github.com/rust-lang/hashbrown for hashmaps

Most of the fastest hash functions are based on multiplications as a
fast and portable way to mix data value bits. Instead of mixing N bits
at a time, you mix NxN bits with a single instruction. However, this
is no longer sufficient: the fastest hash functions now mix two data
words with a single multiplication.

rapidhash, wyHash, and xxHash are exactly this kind of function.

rapidhash and wyHash are very weak in terms of collision
resistance. Please, just look at

https://github.com/wangyi-fudan/wyhash/blob/46cebe9dc4e51f94d0dca287733bc5a94f76a10d/wyhash.h#L130
for wyHash

and
https://github.com/Nicoshev/rapidhash/blob/d60698faa10916879f85b2799bfdc6996b94c2b7/rapidhash.h#L383
for rapidhash

Basically, they contain the following code:

update(state, mum(data64[n]^constant,data64[n+1]^state))

wheremum isuint64 mum(a uint64,b uint64) {uint128 r=a*b; return (uint64)r ^ (uint64)(r>>64);}

Ifdata64[n] == constant, thenmum returns zero independently of the
value ofdata64[n + 1]. As a result, it is easy to generate many
inputs with the same hash value, causing hash tables to exhibit
quadratic behavior and enabling denial-of-service attacks on servers
that use hash tables.

Go uses AES instructions (on some x86 and arm64 CPUs) for map
hashing. If AES instructions are unavailable, it uses a hash function
“inspired by wyHash,” but without this vulnerability. It contains
analogous code:

https://github.com/golang/go/blob/532e3203492ebcac67b2f3aa2a52115f49d51997/src/runtime/hash64.go#L49-L51

However, instead of constants, Go uses randomly generated values. This
considerably decreases hash speed (because it requires additional
memory reads), but it makes the hash function much less vulnerable.

xxHash is somewhat better than wyHash and rapidhash. It has the
following code:

https://github.com/Cyan4973/xxHash/blob/66979328cf3f15cecdc61ea58c9f81e6071f8983/xxhash.h#L4787-L4791

which is essentially:

update(state, mum(data64[n]^constant1 + seed,data64[n+1]^constant2 - seed))

If the seed is known, the same type of attack can be
performed. Therefore, xxHash should not be used with the default or
any other constant seed.

The solution to collision attacks against multiplication-based hash
functions is either not to mix two data words in a single
multiplication, or to detect zero multiplication and always return
value which dependent on both values. The first approach significantly
reduces hash speed. The second approach has a much smaller performance
impact, since modern CPUs allow such code to be vectorized and written
without introducing branches.

VMUM V2 uses the later approach and
has performance competitive with wyHash, rapidhash, and xxHash.

In brief, using RapidHash and wyHash is dangerous. XXHash should only
be used with randomly generated seeds. SipHash is a safe choice (like
VMUM V2), as it is collision-resistant regardless of the seed. (Full
disclosure: as the author of VMUM V2, I may be biased.)

Anonymous wrote in#note-9:

**In brief, using RapidHash and wyHash is dangerous. XXHash should only be used with randomly generated seeds. SipHash is a safe choice (like VMUM V2), as it is collision-resistant regardless of the seed. (Full disclosure: as the author of VMUM V2, I may be biased.)**

---

Thank you for this awesome reply! I learned a lot from it. I do appreciate the thorough explanation of the issue with these multiplication based hash functions.

Note that thea5hash algorithm explains this same problem (I believe) which is called "Blinding Multiplication". This is new terminology to me so I'm leaving it here in the event others find it helpful.

I used both arandom secret and seed when incorporating XXH3 into ruby.

@samyron (Scott Myron) if you wish to bring this forward, I'd suggest to try ruby-bench headline benchmarks:https://github.com/ruby/ruby-bench?tab=readme-ov-file#specific-categories

If your patch does show an improvement on these much more general and meaty benchmark I think it would be strong argument in favor.

And either way, if you want this patch to get attention, you'll have to add it to the devmeeting agenda.