Incorrect output in Safari

[louismullie]

The tests fail in Safari:

Safari/537.71
Starting...
0123456789abcdef

FAILED
expected: 77d6576238657b203b19ca42c18a0497f16b4844e3074ae8dfdffa3fede21442fcd0069ded0948f8326a753a0fc81f17e8d3e0fb2e0d3628cf35e20c38d18906
actual:   fc36244d7cf957112100ab117b5304223313b1018172d2d83353ac17d94e1c8aa8aa6209d10c7cf61f8d857450bb0362f64ad0afbed56c918e483cf5ba3e1865
FAILED
expected: 77d6576238657b203b19ca42c18a0497f16b4844e3074ae8dfdffa3fede21442fcd0069ded0948f8326a753a0fc81f17e8d3e0fb2e0d3628cf35e20c38d18906
actual:   fc36244d7cf957112100ab117b5304223313b1018172d2d83353ac17d94e1c8aa8aa6209d10c7cf61f8d857450bb0362f64ad0afbed56c918e483cf5ba3e1865
Milliseconds for //16/1/1: 2
FAILED
expected: fdbabe1c9d3472007856e7190d01e9fe7c6ad7cbc8237830e77376634b3731622eaf30d92e22a3886ff109279d9830dac727afb94a83ee6d8360cbdfa2cc0640
actual:   6a65f21e66f93eb464625a8d0eeb4d90fbee8f4ae45a27edd1a4752ed69ec442537071e7336d789327995407e393c9d475901b96acee8f0a6858497bef76b068
Milliseconds for password/NaCl/1024/8/16: 1121
Milliseconds for pleaseletmein/SodiumChloride/16384/8/1: 1093

...done.

[tonyg]

Yes, this is puzzling. Any ideas? I've seen the same for js-nacl. I wrote the following in the js-nacl readme - perhaps it should be transplanted to the js-scrypt readme, too? If you can contribute more information about exactly which versions of Safari work (or fail to work), that'd be greatly appreciated. (N.B. enabling/disabling Javascript debugging seems to affect the fault, or at least it does for me!)

WARNING: This code will not run in Safari version 5.1.x; or, at least, will not run when Safari's Javascript debug mode is disabled. Symptoms include corruption during hash calculation, failures when unboxing, and failures when producing and verifying signatures. Safari 7.0 seems to be just fine, however. I don't know exactly at which version Safari started working: I don't have access to enough of a range of systems. The code has run fine on Chrome and Firefox across all the versions I've tried.

[louismullie]

Although I haven't had a chance to look at the code in detail yet, my intuition would be that it's a problem with format conversions (? byte to hex, flip endian) or some other low-level string formatting stuff that Javascript doesn't handle elegantly, and which could be implemented inconsistently.

[ixro]

This issue is occurring on iOS as well, as expected.

Users on Subrosa are unable to sign in across Safari (including iOS) or non-Safari devices.

[3nsoft]

@ixro there is in the wild a js re-write of C code that goes into scrypt. It is written so that you may indicate with a progress bar how far you are in the progress, which is a very useful feature in UI.
It is https://github.com/dchest/scrypt-async-js
Its try it page is http://dchest.github.io/scrypt-async-js/demo.html
Notice that code is written for p=1.
On a try it page, you pass logN, i.e. 14 for interactive, and 20 for more paranoid. 20 goes for a long time, but it completes calculation.
It better be written for web-worker anyway.

[hrobeers]

Any updates on this?

In chrome on desktop this lib seems to be only a little bit faster than scrypt-async-js.
However in firefox on my phone the difference is huge!

js-scrypt:
Milliseconds for pleaseletmein/SodiumChloride/16384/8/1: 1087
scrypt-async-js:
scrypt: 67715 ms QhOsrnYvgZPVi78AZMmq3AvR63iyzbqAQqfdSTkO910=

Thinking of using js-scrypt as a performance improvement for phones that support it.

[tonyg]

The tests pass on Safari/601.6.17. I don't have access to iOS variants or older versions anymore; do any others in the thread still experience problems? (N.B. I just recompiled js-scrypt with a new emscripten the other day, and moved to scrypt 1.2.0.)