lovell / highwayhash Goto Github PK
View Code? Open in Web Editor NEWNode.js implementation of HighwayHash, Google's fast and strong hash function
License: Apache License 2.0
highwayhash's People
Contributors
Stargazers
Watchers
Forkers
allenluce icaas scottinet pombredanne terragona nicknaso appcoreopc evaluation-alex sullof ngagne jaggedsoft cdnbacon blockbunker rensdn suryatmodulushighwayhash's Issues
Performance Discrepancy
I just published a little experiment. It's an npm package that binds to the rust port of highwayhash. The rust and C++ implementations have similar performance characteristics, but the npm benchmarks differ by 2x (in favor of the rust bindings). I'm haven't investigated why this occurs (maybe highwayhash is not using AVX2 🤷 )
Benchmark Code
const { HighwayHash } = require("highwayhasher");
const { asBuffer } = require("highwayhash");
const { assert } = require("console");
const key = Buffer.alloc(32, 1);
function timeIt(name, fn) {
const start = process.hrtime.bigint();
const res = fn();
const end = process.hrtime.bigint();
console.log(`${name} ${(Number(end - start) * 1e-6).toFixed(2)}ms`);
return res;
}
(async function () {
console.time("initialize native");
const nativeMod = await HighwayHash.loadModule();
console.timeLog("initialize native");
const inputs = [
1,
10,
100,
1000,
10000,
100000,
1000000,
10000000,
100000000,
];
// first: a warmup round
for (let index = 0; index < inputs.length; index++) {
console.log(`hashing data of size: ${inputs[index]}`);
const data = Buffer.alloc(inputs[index], 1);
const native = nativeMod.create(key);
native.append(data);
native.finalize64();
asBuffer(key, data);
}
// then record actual timings
for (let index = 0; index < inputs.length; index++) {
console.log(`hashing data of size: ${inputs[index]}`);
const data = Buffer.alloc(inputs[index], 1);
const nativeRes = timeIt("hash native", () => {
const native = nativeMod.create(key);
native.append(data);
return native.finalize64();
});
const thirdRes = timeIt("3rd party", () => {
return asBuffer(key, data);
});
assert(
Buffer.from(nativeRes.buffer).equals(thirdRes),
"hash packages agree"
);
console.log();
}
})();Figured I'd just drop a line in case there was an unintended performance regression somewhere.
Generates collisions way too easily
I think there is something wrong in the current implementation:
$ node -v
v6.9.2
$ node
> const key = require('crypto').randomBytes(32)
> const hh = require('highwayhash')
{ asBuffer: [Function: asBuffer],
asString: [Function: asString],
asHexString: [Function: asHexString],
asUInt32Low: [Function: asUInt32Low],
asUInt32High: [Function: asUInt32High] }
hh.asHexString(key, Buffer.from('foobarfoo'))
'b44c325151095a73'
hh.asHexString(key, Buffer.from('foobarfoobar'))
'b44c325151095a73'
This should not generate the same hash.
In its current state, I believe this module should not be used.
typescript definitions are not included in the latest release on nom
Hi,
It seems the typescript definitions hasn't been included in the latest release on nom
Support for streaming?
How do you recommend highwayhash be used for hashing bytestreams?
It seems like the highwayhash library assumes a single buffer interaction--I didn't see anything like a crypto hash .update(Buffer | string) method.
Build fails on M1 (arm64) processor
#38 127.8 prebuild-install WARN install No prebuilt binaries found (target=3 runtime=napi arch=arm64 libc= platform=linux)
#38 128.1 make: Entering directory '/node_modules/highwayhash/build'
#38 128.1 CC(target) Release/obj.target/nothing/../node-addon-api/nothing.o
#38 128.1 AR(target) Release/obj.target/../node-addon-api/nothing.a
#38 128.1 COPY Release/nothing.a
#38 128.1 CXX(target) Release/obj.target/arch_specific/src/highwayhash/arch_specific.o
#38 128.3 AR(target) Release/obj.target/arch_specific.a
#38 128.3 COPY Release/arch_specific.a
#38 128.3 CXX(target) Release/obj.target/hh_avx2/src/highwayhash/highwayhash_target.o
#38 128.3 g++: error: unrecognized command line option ‘-mavx2’
#38 128.3 make: *** [hh_avx2.target.mk:119: Release/obj.target/hh_avx2/src/highwayhash/highwayhash_target.o] Error 1
#38 128.3 make: Leaving directory '/node_modules/highwayhash/build'
CPU Mining Software Integration?
Could you please tell me if it is possible to easily integrate the HighWayHash into the most Known CPU Mining Softwares because +80% of the World People are using CPUs!
People are leaving the Crypto Mining World because Electricty costs are very high! So, when implementing a new auto-switchable version with HighWayHash (All OS), we will have the best one! Fast Mining, Fast Jumping to The New Digital World, fast Global Network!
Thanks in advance
Requires a buffer as input
Hi,
I don't know if the documentation is wrong or if it states a functionality that is not yet implemented, but in its current state, this module takes only a Buffer object as input arguments, while the documentation uses a plain string to show how to use this module.
I would submit a pull request, but I'd rather let you decide if the problem lies in the documentation or the implementation. :-)
To reproduce:
$ node -v
v6.9.2
$ node
> const hh = require('highwayhash');
{ asBuffer: [Function: asBuffer],
asString: [Function: asString],
asHexString: [Function: asHexString],
asUInt32Low: [Function: asUInt32Low],
asUInt32High: [Function: asUInt32High] }
> hh.asHexString(require('crypto').randomBytes(32), Buffer.from('foobar'));
'81aa3aeea2e1f9dd'
> hh.asHexString(require('crypto').randomBytes(32), 'foobar');
Error: Expected input to be a Buffer: foobar
at assertInput (/var/app/node_modules/highwayhash/index.js:13:11)
at Object.asHexString (/var/app/node_modules/highwayhash/index.js:30:5)
at repl:1:4
at sigintHandlersWrap (vm.js:22:35)
at sigintHandlersWrap (vm.js:96:12)
at ContextifyScript.Script.runInThisContext (vm.js:21:12)
at REPLServer.defaultEval (repl.js:313:29)
at bound (domain.js:280:14)
at REPLServer.runBound [as eval] (domain.js:293:12)
at REPLServer.<anonymous> (repl.js:513:10)
Support for 128 or 256 bit hashes?
Thanks for this work!
Is there an API to switch the result buffer to render 128 bit or 256 bit hashes? Providing an HHResult128 or HHResult256 to the constructor should suffice. I looked but didn't find anything promising.
N-API support
Hi @lovell ,
I worked on this native addon and I ported it to N-API
You can find my work here: https://github.com/NickNaso/highwayhash/tree/napi
If you want experiment with N-API you can create a branch and call it "napi" so I can execute the PR on it.
After that we can iterate to over it and at the end publish a tagged version of highwayhash like reported here: https://nodejs.org/en/docs/guides/publishing-napi-modules/
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.