Problems when using bcrypto with Electron about bcrypto HOT 11 CLOSED

Pinging @mslipper (who is building an electron application that requires bcrypto)

from bcrypto.

I'm not familiar with how electron actually builds native addons, but it sounds like it's not linking to openssl properly.

Note that bcrypto abuses the fact that node.js statically links to its own version of openssl (this is different from whatever system version of openssl you have installed). All of the openssl symbols are exported from within the node.js binary, so we just include the openssl header files to access them.

How this works within electron, I have no idea. RIPEMD160_Init and RAND_status have been exposed in openssl for a long time, so it sounds like electron is not linking to openssl?

As a temporary solution, you can always fall back to the pure javascript backend. Though, I don't recommend this since it's much slower and lacks a lot of important security properties like constant-time signing. That said, we do try to use blinding factors for every algorithm's signing function (I'm not sure whether this actually holds up in an adversarial environment though. We would probably need experts to look at it in order to determine whether it is truly secure against side channel attacks).

from bcrypto.

We ran into this issue as well. We had to fall back to JavaScript in our application. Electron links against a special, Electron-specific version of Node. When you build your application, electron-builder (or some other tool) will recompile your binaries for that Node version. Unfortunately, Electron Node links against BoringSSL for cryptography. This also means that you will be unable to use the Node backend, since the Electron Node version does not include RIPEMD160 and a variety of other cryptographic primitives. See electron/electron#16195 for more information.

from bcrypto.

Hmm, might be time to consider switching the native backend to a statically linked nettle. Not an easy task, but probably worth it in the long run to avoid these kinds of issues with different node builds.

from bcrypto.

Thanks for your feedback. I really appreciate it.

from bcrypto.

For clarity, Electron does include ripemd160 (via BoringSSL—Electron >= 4 does not include OpenSSL), but we don't export the native symbols currently. See electron/electron#13176.

from bcrypto.

@nornagon, thanks for the info. It would be super useful if electron were to export the boringssl symbols in the future. It doesn't seem like there are too many differences between openssl and boringssl (see https://boringssl.googlesource.com/boringssl/+/HEAD/PORTING.md).

edit: fixed link.

from bcrypto.

@j-a-m-l, @mslipper, I've pushed an experimental nettle branch. It's slightly slower than the openssl one, but it should build for electron (it's also possible to compile it to wasm if we take the time to write the backend).

If we have enough people test it and it works, we can probably consider switching to it altogether. Nettle is a much nicer library than openssl (albeit slower in some cases, like hashing). I like that they also have plans to add ed448 support within the next release or two. This allows us to drop 90% of our custom written C.

from bcrypto.

In our case we're going to wait probably some time before moving to a new version to avoid introducing incompatibilities or other issues, so I don't know when we will be in a position to test that branch.

Anyway, thanks @chjj for your work.

from bcrypto.

Since OpenSSL functionality has been replaced with libtorsion, I think this may no longer be an issue. I switched the bcrypto backend in bob-wallet to native (from JS) and everything runs fine.

from bcrypto.

Thanks for keeping us in the loop, this may be useful for ArkEcosystem/desktop-wallet#1605 @davimello28

from bcrypto.