Murmur3 32 bit hash mismatch

I’m trying to duplicate the hashes generated by tyk outside of Tyk.

GitHub - TykTechnologies/murmur3: Native MurmurHash3 Go implementation
vs
GitHub - spaolacci/murmur3: Native MurmurHash3 Go implementation” and virtually any other murmur3 implementation seem to disagree:
This online one here: http://murmurhash.shorelabs.com/ also matches all my other libs I’m using in multiple langauges (go, python) except the Tyk murmur3 gets a different answer.

Am I missing something?

Initially, we used GitHub - spaolacci/murmur3: Native MurmurHash3 Go implementation but they made some changes in murmur32 algo, which was a breaking change for us, so we had to do a fork with the previous version.

In 2.7 Tyk Gateway v2.7 we added option to specify hashing algorithm (see release notes), and you can try using murmur64, which is based on latest github.com/spaolacci/murmur3 implementation.

Hope it helps!

Got it. Thanks.

Given that - it would be nice if, along with the RawKey, the Hash value was returned as well given I can’t easily generate it in this case.

1 Like

Actually it is already works like this. When you create key via API, it returns key_hash field.

Ah - perhaps in other places, but not on keys provisioned for developers:

PUT http://tyk-dashboard:3000/api/portal/requests/approve/5b85c3133dda9100018400dd
authorization: ******************

200 OK
Access-Control-Allow-Credentials: true
Cache-Control: no-store, no-cache, private
Content-Security-Policy: default-src * data: blob: 'unsafe-inline' 'unsafe-eval'; script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; connect-src * 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src *; style-src * 'unsafe-inline';
Content-Type: application/json
Strict-Transport-Security: max-age=63072000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Date: Tue, 28 Aug 2018 21:48:03 GMT
Content-Length: 83

{
    "Password": "",
    "RawKey": "5b859c063dda910001fa1c09c8597d2433b0477dbe5aec571cbb0341"
}

I see!

Worth noticing that when you generate key for developer, its hash added to developer object, “subscriptions” map.

Right, I was hoping to avoid the extra API call to get the key hash and based on key hash go straight to the endpoint that gets key info.