search

cryptocoinjs / secp256k1-node

Node.js binding for an Optimized C library for EC operations on curve secp256k1
Other
338 stars 120 forks source link

Consider using WebAssembly for the browser implementation #129

Open kripod opened 6 years ago

kripod commented 6 years ago

Related article: https://blog.bitjson.com/just-released-webassembly-version-of-secp256k1-10x-faster-than-javascript-eb3cebe4d411

dcousens commented 6 years ago

@kripod what is the route for detecting support for that?

kripod commented 6 years ago

@dcousens It isn’t trivial, but I found the following answer on StackOverflow: https://stackoverflow.com/a/47880734

dcousens commented 6 years ago

@bitjson do you encourage users to compile their own WASM? What is the release process for inclusion in a library like this (or others).

fanatid commented 6 years ago

I had seen this article yesterday, performance make impression. Not sure what we should do here, I'd like that users compiled WASM themselves (on same reason why I removed prebuild bindings). Also looks like we need elliptic in any case, because sometimes WASM can be not supported by old browsers.

bitjson commented 6 years ago

@dcousens I don't think it's particularly necessary for users to compile their own. If users are already trusting the javascript they're getting from NPM, they might as well trust the WebAssembly too. If not, users should audit both themselves, and part of doing that would be to run the WASM compilation step (or check that entities they trust have signed it). Not a new problem in the Node.js space though.

For now, I've opted to avoid even PGP signing anything, since I'd rather people not trust me at all. (In the future, I'm hoping to use something more definitive than PGP, like BitAuth, then I might start signing things. 😄)

fanatid commented 4 years ago

WebAssembly + n-api addon in fanatid/fcrypto