incorrect hash in android 4.3.1 and lower

[rubensayshi]

when using createHash('sha256') I'm getting to hash 'synchronous write' I'm getting
1e0a06bb7cb5399c5389c14ff182b700834f9a00bcfd5b0067e12bdde24a5300 instead of 1e0a06bb7cb5399c5389c14ff182b748834f9aedbcfd5bb467e12bdde24a5370.

using crypto-js I'm getting the correct hash.

I'm using this repo to test it with inside an Android 4.3.1 emulator (Nexus 4 Intel Atom x64):
https://github.com/rubensayshi/browserify-cryptojs-android

using node v0.10 or v0.12 to browserify and run cordova doesn't make a difference

[rubensayshi]

idk if it's me or not ...
if anyone has any ideas of things to test without wanting to spend time actually coding/running it then just tell me and I'll do it ;-)

[calvinmetcalf]

what the actual code your using to hash the value, when I do

crypto.createHash('sha256').update('synchronous write').digest('hex');

I get

1e0a06bb7cb5399c5389c14ff182b748834f9aedbcfd5bb467e12bdde24a5370

[rubensayshi]

ooops sorry, yea, was trying difference message, updated original post now.

the odd (or maybe not) thing is that the result is always very similar (when I manually compare I can barely see the difference).

using crypto.createHash('sha256').update('synchronous write').digest('hex') also results in 1e0a06bb7cb5399c5389c14ff182b700834f9a00bcfd5b0067e12bdde24a5300 for me btw

[calvinmetcalf]

yeah looks to be an issue with the sufix of the hash

[calvinmetcalf]

(in the browser createHash and crypto.createHash are actually the same)

[calvinmetcalf]

I hopefully will be able to get to this this weekend

[dcousens]

1e0a06bb7cb5399c5389c14ff182b7 00 834f9a 00 bcfd5b 00 67e12bdde24a53 00 
1e0a06bb7cb5399c5389c14ff182b7 48 834f9a ed bcfd5b b4 67e12bdde24a53 70

1e0a06 bb 7cb539 9c 5389c1 4f f182b7 00 834f9a 00 bcfd5b 00 67e12b dd e24a53 00 
1e0a06 bb 7cb539 9c 5389c1 4f f182b7 48 834f9a ed bcfd5b b4 67e12b dd e24a53 70

It isn't just the suffix, seems to be on the 4th byte (though, not consistently).
Most likely an issue with writeUInt32BE or similar.

[calvinmetcalf]

ok able to confirm that the issue is not present on android 4.4 (which as it turns out is the oldest devise I own) installing the emulator now

[calvinmetcalf]

ok so testing on an emulator running 4.3.3 (modifing the test page to print to the dom) I am unable to reproduce the problem

[calvinmetcalf]

so that being said I am giving another go at setting up browser tests for the whole module family (crypto-browserify/crypto-browserify#139) which should catch this.

[dcousens]

@rubensayshi do you have a more in depth reproduction environment? Can't reproduce either.

[calvinmetcalf]

aha! reproduced it! https://api.travis-ci.org/jobs/83552020/log.txt?deansi=true

[rubensayshi]

I was testing on 4.3.1, maybe 4.3.3 is already version where it's fixed ...
You could also try 4.2.2, same failure

[calvinmetcalf]

it seems to be a issue with the browserify buffer implementation as I've been able to write a failing test there.

[dcousens]

See feross/buffer#81, closing in favour of that