Different result of Hash algorithm

Bug Reports
1

Hi,

I’m trying to use blake2b hash algorithm from https://github.com/dcposch/blakejs in my fuse project. The library is pure javascript implementation with no dependency on browser function. But the thing is, when I run the function on fuse, the result is different compared to when executed on browser or nodejs (or other library in different language with same algorithm).

for example, the 32byte hash of word “test” on blake2b algorithm should output
kosgNmlD4q/RHrwOri5TqTvxd6T881vMZNUDcE5l4gI=

, while in fuse, the result is

Pz8gNmlDPz8/Hj8OPy5TPzs/dz8/P1s/ZD8DcE5lPwI=

The library (blake2js) said that blake2b is 64bit algorithm, and it use some workaround to work with javascript runtime. I have tried running this code in browser (chrome), nodejs, and iOS browser and the result is consistent with any other blake2b implementation. And I have tried to run fuse app with same algorithm in OSX preview and iOS preview and it has wrong result.

I assume that fuse using same V8 engine on preview and android and same javascript engine on iOS safari, but I don’t understand why the result is different while the library has no requirement for browser functionality. Is there any change in fuse that affecting this behaviour?

2

Hi!

Interesting. I have no idea why that would be the case.

Are you aware that it is possible to use Visual Studio Code (free and open source for both OSX and Win) to step-debug javascript in Fuse?

I reccommend opening VSCode and do some step debugging side by side with a browser and see where the behavior starts to differ. Would love to hear how it goes!

3

Hi,

Just debug the code, and it seems that the hash algorithm is working fine, and I think the problem is in the base64 encoder. At first, I thought that the base64 library is the culprit, but it seems that the builtin encode (FuseJS/Base64) also resulting the same. Here is some fact:

Result array

[146, 139, 32, 54, 105, 67, 226, 175, 209, 30, 188, 14, 174, 46, 83, 169, 59, 241, 119, 164, 252, 243, 91, 204, 100, 213, 3, 112, 78, 101, 226, 2]

Browser :
String conversion (using String.fromCharCode)

"’‹ 6iCâ¯Ñ¼®.S©;ñw¤üó[ÌdÕpNeâ"

Hex conversion (using .toString(16))

"928b20366943e2afd11ebceae2e53a93bf177a4fcf35bcc64d53704e65e22"

btoa result

"kosgNmlD4q/RHrwOri5TqTvxd6T881vMZNUDcE5l4gI="

Fuse

String conversion

"’‹ 6iCâ¯Ñ¼®.S©;ñw¤üó[ÌdÕpNeâ"

Hex conversion

"928b20366943e2afd11ebceae2e53a93bf177a4fcf35bcc64d53704e65e22"

btoa / Base64.encodeAscii

"Pz8gNmlDPz8/Hj8OPy5TPzs/dz8/P1s/ZD8DcE5lPwI="

To make sure that the problem in the base64 encoding, I’m using base64 encoder(without btoa) code from github https://gist.github.com/jonleighton/958841 for comparison. And the result is consistent to the browser

I hope this could help

4

Just found this library

And it solves my problem. It seems that fuse built in base64 encoder isn’t always consistent, on same case it results differently compared to the browser. You might need to compare the built in base64 encoder with that library to check. Thanks

5

Thanks for your help in researching this. We definitely have a problem that deviates from the spec here. The problem is how our btoa implementation handles UTF8 encoded characters (since btoa is only meant to be used on ASCII). I will file a ticket and make sure this gets fixed.