Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider switching to a nettle backend #23

Open
chjj opened this issue Jun 12, 2019 · 0 comments
Open

Consider switching to a nettle backend #23

chjj opened this issue Jun 12, 2019 · 0 comments

Comments

@chjj
Copy link
Member

chjj commented Jun 12, 2019

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:

  1. It's slower than openssl, especially for hashing. EC is also relatively slow (in nettle, nothing is done in variable time, even during verification).
  2. 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).
  3. 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.

No solution for #3.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant