crypto_hash_sha256 not supported

[moore]

I was trying to understand why it is missing but I have never used Emscripten before. So I have not worked it out yet.

[tonyg]

It's missing because each function needs some hand-written wrapper code to be produced. For example, see crypto_hash() in nacl_cooked.js. If specific primitives are important to you, I'd be happy to incorporate a patch with the necessary wrapper code.

[moore]

I saw that and tried to add it my self but the crypto_hash_sha256 call did not seem to be in the Emscripten-compiled Javascript. It would be great if you could add it. Right now I am using sjcl for my sha256 needs and js-nacl for my encryption. I would rather just use js-nacl only.

I also expect that I may end up setting up a build environment for js-crypto so I can hack on it but I was going to wait till ubuntu 13.4 comes out on the 25 so I don't have to compile my own llvm :)

Thanks for you work on this. I have so far enjoyed using it.

[tonyg]

Oops! You're quite right! The import.py script wasn't producing crypto_hash_sha256 (and friends) as exported symbols, so they were being stripped out of the final emscripten-produced build. I've changed it to include all available functions (commit 29c00cb) and then added the necessary wrapper code for crypto_hash_sha256 (commit 72a5808).

PS. Very glad to hear you're enjoying the library :-)

[moore]

Thanks, I will try it out later tonight. I really did not want to try and understand import.py

I really prefer your arraybuffer approach and I it means I can just use nacl in my C back end too.

By the way do you have any performance benchmarks comparing js-nacl to sjcl ( current fastest? ) I am going to use js-nacl either way I was just wondering how it performed.

[tonyg]

No, I don't have any speed comparisons against sjcl; all I have so far is http://www.eighty-twenty.org/index.cgi/tech/benchmarking-nacl-and-scrypt-in-the-browser-20130331.html.

Would you care to write something similarly crude - something analogous to benchmark.html - that we could use to get a rough impression?

[tanx]

I did some brief comparisons. Sjcl's symmetric aes-ccm is faster than
js-nacl's secretbox in my tests.

The asymmetric box functions and keygen in js-nacl was faster than sjcl.
Both use ecc if Im not mistaken.

This should improve in the future though as emscripten and asm.js
optimizations mature.

[moore]

O cool thanks.

"The asymmetric box functions and keygen in js-nacl was faster than sjcl. Both use ecc if Im not mistaken."

Yes they do but sjcl uses ecdsa and sj-nacl uses Dan and Tanya's 25519
functions.

"This should improve in the future though as emscripten and asm.js optimizations mature."

I was thinking of also looking in to PNACL to provide a fast chrome
nacl implementation. Would you be interested in integrating that with
js-nacl so that it used the google native code implementation when possible
and fell back to js other wise?

[tonyg]

@tanx, how much faster, would you say? 10x? 5x? 2x?

@moore, Absolutely! If some kind of compatible API can be developed which can take advantage of any native implementations available, that'd be ideal. It'd be great to get Firefox and Chrome plugins accelerating the functions.

[tanx]

I would say in the range of about 2x.

Am 23.04.2013 um 13:47 schrieb Tony Garnock-Jones <notifications@github.com

:

@tanx https://github.com/tanx, how much faster, would you say? 10x? 5x?
2x?

@moore https://github.com/moore, Absolutely! If some kind of compatible
API can be developed which can take advantage of any native implementations
available, that'd be ideal. It'd be great to get Firefox and Chrome plugins
accelerating the functions.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/7#issuecomment-16853403
.

[tonyg]

OK, that's not so bad. Perhaps as emscripten develops to better support asm.js the gap will narrow.

[moore]

It would be worth doing a little profiling, it is possible that some of that cost is in nacl_coocked.js. It looks to me like there is are two copies every time you perform a crypto operation due to inject_bytes, and then extract_bytes. I just poked around some and I think something could be done here. For instance ignoring the memory leak and avoiding free, extractBytes could be reimplemented as:

function extractBytes(address, length) {
return nacl_raw.HEAPU8.subarray(address, address + length) ;
}

Or even using slice might be faster the the current implementation:

function extractBytes(address, length) {
return new Uint8Array ( nacl_raw.HEAPU8.buffer.slice(address, address + length) ) ;
}

In any case I think more testing is warranted. I will work on it once I get my code feature complete and switch to optimizations.

This is a strange and dark land I am about to wander into...