Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interoperability with other implementations of FNV-1a #2

Closed
mjradwin opened this issue Apr 29, 2014 · 7 comments
Closed

Interoperability with other implementations of FNV-1a #2

mjradwin opened this issue Apr 29, 2014 · 7 comments

Comments

@mjradwin
Copy link

How would you propose using your fnvplus.seed() API to support using the standard offset_basis values as described in draft-eastlake-fnv-06.txt?

We would like to be able to initialize fnvplus so it is compatible with Appendix C: A Few Test Vectors :

var fnv = require('fnv-plus'),
    assert = require('assert');

assert.equal(fnv.hash('',       64).hex(), 'cbf29ce484222325');
assert.equal(fnv.hash('a',      64).hex(), 'af63dc4c8601ec8c');
assert.equal(fnv.hash('foobar', 64).hex(), '85944171f73967e8');

In our Java application, we generate unique IDs using 64-bit FNV-1a. For the same given string we would like to be able to generate the identical hash values in JavaScript using fnv-plus. The fnvplus.seed() implementation does allow the caller to specify a seed value, but that value is transformed (through hashing) so it can't be used as an offset_basis.

@tjwebb
Copy link
Owner

tjwebb commented May 11, 2014

So, there are two issues at hand here:

  1. The offset_basis is actually a hash; the default seed is actually an FNV-0 hash of the string chongo <Landon Curt Noll> /\../\. So I can make my API clearer to this effect: that the input into seed() will be hashed using FNV-0. If it were not, some other strategy e.g. modulus would need to be used to ensure that the seed is within the keyspace of the target hash function.
  2. It is the case that I do not test fidelity to the reference implementation in this manner, which may result in seeing output that doesn't seem to line up with your existing hashes. I will take a closer look at this and give you an update on my findings.

@tjwebb tjwebb self-assigned this May 11, 2014
@tjwebb
Copy link
Owner

tjwebb commented May 11, 2014

I hadn't noticed this before, but it makes sense now: the reference offset_basis values are actually computed using FNV-1, and not FNV-1a, and so my offsets will not match the reference offsets. IMO this is basically historical error, but I should nevertheless conform to the extant literature. I will correct this in v1.2.7.

@tjwebb tjwebb closed this as completed in 79cb43c May 11, 2014
tjwebb pushed a commit that referenced this issue May 11, 2014
@tjwebb
Copy link
Owner

tjwebb commented May 11, 2014

@mjradwin
Copy link
Author

Awesome, thanks! I will pull the latest and confirm your fix.

@tjwebb
Copy link
Owner

tjwebb commented May 12, 2014

Great, let me know.

@mjradwin
Copy link
Author

Pulled 1.2.7 from npm and everything's working great!

@tjwebb
Copy link
Owner

tjwebb commented May 12, 2014

Excellent. Thanks for your feedback

@tjwebb tjwebb mentioned this issue Feb 27, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants