srijs / rusha Goto Github PK

Hello!

I've just opened a PR to add typings for this library over at DefinitelyTyped: DefinitelyTyped/DefinitelyTyped#49123.

If you're still working on this, would you be able to review my PR?

While I don't have a big-endian platform for testing, it looks like rusha won't work correctly there. Reason is: the switch (om) and switch(lm) blocks in functions like convBuf() reverse byte order - assuming little-endian architecture. Most other places such as getRawDigest() function for example seem to work independently of platform's architecture.

If I have a string like "café", something with an accent eigu, and I want to SHA1 hash it with rusha.js, how would I do this? Since it's not ASCII, could I somehow convert it into binary?

This might gain some performance by re-using typed array allocations.

I'm using a package in a service worker that has rusha somewhere in it's dependency tree, and something I noticed is that rusha is attaching itself to the 'message' event in the service worker and tries to hash every message that it receives. Is this on purpose and if so is there a way to disable this?

As a side note, service workers don't have postMessage defined globally so every time a message is sent to the worker an exception is raised when rusha handles the event.

Add support to calculate hashes on the fly for chunks of data.

The goal is to be compatible to Node.JS' crypto.createHash. (http://nodejs.org/api/crypto.html#crypto_crypto_createhash_algorithm)

Steps to be done:

✓ Transfer all RushaCore context to the heap
✓ Isolate function to pad data
-- Add fill state that indicates fullness of buffer and acts as write-offset for conv
-- Add update and finalize methods
-- Factor both methods into an object returned by the createHash method

This is making npm install take ages but isn't actually used in the code. I'm guessing someone accidentially did a npm install <module> -S instead of npm install <module> -D
https://github.com/srijs/rusha/blob/master/package.json#L48

The Readme says to use the Hash API, but does that expose getState/setState?
Is there currently a way to use this library in order to resume a previous hash operation?

rusha = require('rusha');
const hasher = new rusha.createHash();
console.log(hasher.getState()); // fails with Uncaught TypeError: hasher.getState is not a function

Create multiple integration examples (vanilla/CDN, browserify, webpack) and use those as integration test during CI.

I'm seeing this error while hashing some data:
TypeError: asm.js link error: ArrayBuffer byteLength 0x200 is not a valid heap length. The next valid length is 0x1000

Hi,

I need to calculate SHA hash code for every image file in a folder.
Usually this folder has thousands of files and each file are larger than 5MB.
In this way, it is important to calculate SHA code for all the files prior to their upload, because it is an way I have to check whether that file has been already uploaded and then skip uploading it.
This problem is very simple, but I'm facing lots of troubles finding a way to code an efficient javascript code to handle this.
In my implementation: https://gist.github.com/fernandoc1/27c617d4caba87b243de
the browser freezes when I select lots of files.
Can someone give me a tip on how to solve this?

When using Rusha with browserify, Rusha._core is undefined and gives the following error:

TypeError: Rusha._core is not a constructor

On this line.

Here's my guess as to what's going on:

In a commonJS environment Rusha is not put on the window, which is expected. The line that's referring to Rusha._core should still work because the function is named Rusha and code inside a function can refer to that function if it has a name. But for some reason, this doesn't seem to happen in Firefox when ASM is enabled.

To solve this, could we just put Rusha._core in a local variable named Core and refer to that to fix this in Firefox?

Tested on Firefox 31. ASM may have improved on newer versions to fix this bug.

the README.md has the following for the second graph "Results per Implementation and Platform, smaller is better, again"

however the graph itself has "(bigger is better)", which appears to be the correct statement.

When constructing the core, rusha currently passes two constructors via stdlib parameter: Int32Array and DataView. The former is being used, the latter isn't. In fact, the way I read the spec, asm.js isn't even allowed to use DataView.

The current version in bower is outdated, can you please keep it up to date with the NPM version or remove support for bower? I spent several hours trying to figure out why I was getting different hashes in my node app vs the browser app and it turned out that the bower version was older and had a bug with Uint8Arrays that had a byteOffset on the underlying ArrayBuffer. Thanks

It seems totally strange that this could be happening in js, but I'm getting a segfault with this in node.js

I have been benchmarking js hash implementations and before 0.7.8 rusha does very very well,
but with 0.7.8 or 0.8.0 it gets a segfault!

clone this repo: https://github.com/dominictarr/crypto-bench
and run npm install

then I get this output:

run (N), input-size (bytes), ops (bytes/ms), time (ms)
1, 1, 8.17, 0.12239902080783353
3, 2, 31.24, 0.06402048655569782
5, 3, 31.71, 0.0946073793755913
7, 4, 32.48, 0.12315270935960591
Segmentation fault (core dumped)

this does create many hashes in quick succession... maybe that is related?

Generate random chunks of data and compare against Node.js built-in crypto.

Will fail since reader is undefined.

Rusha relies on FileReaderSync for blob reading.

Current API doesn't permit us using FileReader, since the API is synchronous, but FileReader is async.

Are you planning to add more hashing algorithms? I'm using rusha to compute HMAC codes and the backend might require HMAC-SHA-256 instead of HMAC-SHA-1. I really don't wanna use a different (slower) library for that.

In rusha.min.js:2:3938
TypeError: asm.js type error: duplicate name 'e' not allowed
It happens with latest rusha.min.js from this repo ( https://raw.githubusercontent.com/srijs/rusha/2b6e4c1e55592f4386d1ded2e325cd07d73fd49d/rusha.min.js )
Previous version from march 2015 ( https://raw.githubusercontent.com/srijs/rusha/c14c28833ab28b270352f99f9ecc4db7d49baf0d/rusha.min.js ) does not have this problem.
Please minify it with asm.js-compatible tool. (for me, uglifyjs done good job, but maybe it's factor of luck which names are randomly chosen for mangling variable names)

Are there any golang equivalent implementation of rusha?

Consider to use sweet.js' hygienic macros to produce rusha.js instead of the now used, somewhat hacky C preprocessor thing.

Tiny issue but since I noticed it I thought I would report it. In function rawDigest() the variable last is declared but never used.

Hi,

I'm having problems using rusha for comparing a string in Javascript with the same string hashed in PHP.

In Javascript, I use

var sha=new Rusha(); sha.digest("\u00e4")
"7e5c0f7aba32cf3e22fd30c4513a21e6d1c3aeff"

and in PHP (once using a literal ä, once a json-decode'd ä to rule out a bug in PHP or my file encoding)

$c1="ä";
$c2=json_decode("\"\\u00e4\"");
echo "1: -$c1- 2: -$c2-\n";
echo json_encode($c1)."\n";
echo json_encode($c2)."\n";

echo sha1($c1)."\n";
echo sha1($c2)."\n";

which gives me the output

1: -ä- 2: -ä-
"\u00e4"
"\u00e4"
961fa22f61a56e19f3f5f8867901ac8cf5e6d11f
961fa22f61a56e19f3f5f8867901ac8cf5e6d11f

Why are the SHA1 hashes different? After all, using the \u00e4 notation should result in the same byte sequence both in a PHP string and a Javascript string, right?

Investigate using karma with browserstack or saucelabs to test across a wider range of browsers and operating systems.

TypeError: asm.js link error: ArrayBuffer byteLengths smaller than 64KB are deprecated and will cause a link-time failure in the future

This is while hashing with Firefox 34.

Any change you could publish the latest goodness to npm?

Thanks!

I couldn't track down the exact spot where I started getting problems, but it's very close to 1GB.

This is tested against node's crypto library as well as c#'s hashing (which are both the same).

I'm digging around in the SHA1 spec, but I don't really have that kind of background.

Congrats on writing some nice code. I'm especially impressed that you figured out how to use asm.js correctly and packaged the script to work in a worker.

I only have one nitpick and that is that I feel you've misrepresented my sha1 code in cifre. I only accept binary input, you have to convert ascii strings to binary using the provided conversion tools https://github.com/openpeer/cifre/blob/master/utils.js#L94-L114 which are unicode safe and utf8 encode for all unicode points javascript supports (BMP).

I did have a bug in my code that caused it to give incorrect hashes for inputs over 64 bytes long that I just fixed. hookflash/obsolete.cifre@bd2fbc2

I would love if you included my code in the benchmark to see where it stands and corrected the statement about mine only supporting small ascii strings.

Allow to provide a callback that is called after a chunk us completed or trigger a progress event.
The best place to call this is at the end of the coreCall method.

Hi,

I'm receiving the following error, when passing an ArrayBuffer to rusha.js

Uncaught TypeError: Cannot read property 'byteLength' of undefined rusha.js:282

Here is the code that I'm using:
https://gist.github.com/fernandoc1/79ee1d0721c399519fa5

Would someone help me finding what is going wrong?

//import
const rusha = require('rusha');

//set up worker
const worker = rusha.createWorker();

// send data to be hashed
worker.postMessage({id: myjobid, data: mydata});

How do I retrieve the hash and terminate the worker?

Shared workers and service workers do not have postMessage defined in their global scope so when they receive a message and attempt to call postMessage a ReferenceError is thrown.

Maybe it's best to only attach the message listener if the global scope is of type DedicatedWorkerGlobalScope?

Rusha produces wrong hash values for files with sizes greater or equal 512MB.

Rusha is not meant to have any kind of limitation in terms of file sizes, so this is definitely a bug in Rusha, or a limitation of the underlying system.

The fact that up to 511MB everything works fine might point to some of the padding or conversion calculations not being correct, since the "core" rusha routine is being run for every chunk (64K by default) in the same manner, and I wouldn't expect it to suddenly work differently.
Note: I've tested it with chunk sizes of 16bk ans 2Mb, being the result incorrect, too.

I'm getting this warning in the console when using Rusha in Firefox:

"TypeError: asm.js type error: expecting argument type declaration for 'e' of the form 'arg = arg|0' or 'arg = +arg' or 'arg = fround(arg)'"

You can see it in action here: https://instant.io/