You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm a huge fan of libnettle. It's really small, well-written, and easily auditable. We could vendor it and statically link to it. Switching would solve issues like #15. It would avoid the dangers of calling out to potentially many different openssl versions.
As an added bonus, it would allow us to compile bcrypto to web assembly (we could add a fourth wasm backend). Nettle compiled to wasm doesn't seem to be significantly faster than our JS backend. Furthermore, google has pretty much ruined any possibility of using web assembly in the browser due to their arbitrary 4kb limit for synchronous wasm module loading (once the mass migration to firefox begins, this will be less of an issue). That said, a wasm backend would compensate for the lack of constant-time functions in the JS backend (assuming v8's wasm vm is actually doing that stuff in constant-time -- who knows what it's actually doing behind the scenes).
I currently have a development branch utilizing nettle. It supports pretty much everything, including a custom implementation of bip-schnorr.
I believe nettle will include ed448 support within the next version or two, which would allow us to drop most of our custom C code.
The downsides:
It's slower than openssl, especially for hashing. EC is also relatively slow (in nettle, nothing is done in variable time, even during verification).
It doesn't support secp256k1 (we could still use libsecp256k1 for this, but it would be nice to support nettle's ecdsa backend as an option).
The build becomes longer and more complex.
For #1, we could optionally allow for openssl support just for fast hashing.
As far as #2 goes, there's an unfinished patch for secp256k1 on the nettle mailing list, but it seems to be missing the most important parts (e.g. the reduction/modulo functions). We would have to write our own reduction functions for the order and prime (we might be able to re-use the libsecp256k1 scalar reduction function, but the prime reduction is probably useless to us since it uses a different word size than gmp limbs). Anyway, not super important right now.
I'm a huge fan of libnettle. It's really small, well-written, and easily auditable. We could vendor it and statically link to it. Switching would solve issues like #15. It would avoid the dangers of calling out to potentially many different openssl versions.
As an added bonus, it would allow us to compile bcrypto to web assembly (we could add a fourth wasm backend). Nettle compiled to wasm doesn't seem to be significantly faster than our JS backend. Furthermore, google has pretty much ruined any possibility of using web assembly in the browser due to their arbitrary 4kb limit for synchronous wasm module loading (once the mass migration to firefox begins, this will be less of an issue). That said, a wasm backend would compensate for the lack of constant-time functions in the JS backend (assuming v8's wasm vm is actually doing that stuff in constant-time -- who knows what it's actually doing behind the scenes).
I currently have a development branch utilizing nettle. It supports pretty much everything, including a custom implementation of bip-schnorr.
I believe nettle will include ed448 support within the next version or two, which would allow us to drop most of our custom C code.
The downsides:
For #1, we could optionally allow for openssl support just for fast hashing.
As far as #2 goes, there's an unfinished patch for secp256k1 on the nettle mailing list, but it seems to be missing the most important parts (e.g. the reduction/modulo functions). We would have to write our own reduction functions for the order and prime (we might be able to re-use the libsecp256k1 scalar reduction function, but the prime reduction is probably useless to us since it uses a different word size than gmp limbs). Anyway, not super important right now.
No solution for #3.
The text was updated successfully, but these errors were encountered: