-
Notifications
You must be signed in to change notification settings - Fork 41
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
Problems when using bcrypto with Electron #15
Comments
Pinging @mslipper (who is building an electron application that requires |
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. 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). |
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, |
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. |
Thanks for your feedback. I really appreciate it. |
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. |
@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. |
@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. |
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. |
Since OpenSSL functionality has been replaced with libtorsion, I think this may no longer be an issue. I switched the bcrypto backend in |
Thanks for keeping us in the loop, this may be useful for ArkEcosystem/desktop-wallet#1605 @davimello28 |
I'm using Ubuntu 18.04 with OpenSSL 1.1.1, and
bcrypto
works flawlessly on Node console, but when executing inside Electron some problems arise:3.0.2
I can run the project, but, it fails when using
RIPEMD160
:symbol lookup error: /home/desktop-wallet/node_modules/bcrypto/build/Release/bcrypto.node: undefined symbol: RIPEMD160_Init
3.1.5
In this case, this happens before display the Electron window:
symbol lookup error: /home/desktop-wallet/node_modules/bcrypto/build/Release/bcrypto.node: undefined symbol: RAND_status
Any idea about the root cause?
The text was updated successfully, but these errors were encountered: