Consider using react-native-quick-crypto

[mrousavy]

Hey!

I noticed this repo uses react-native-crypto, which itself uses crypto-browserify under the hood. crypto-browserify is a JS-based implementation for crypto, which is slower than Margelo's react-native-quick-crypto, since that uses C++ (OpenSSL) with JSI under the hood.

If you want to replace react-native-crypto with the faster react-native-quick-crypto, I'm happy to help out or answer questions! 😄

[revan-zhang]

Hi @mrousavy

Thanks for your suggestion, our project is a fully cross platform project with web and browser extension in addition to ios/android, this is a very critical reason why we didn't choose the native crypto library before like react-native-quick-crypto.

If using react-native-quick-crypto. It is necessary to encapsulate different functions executed for different platforms in some crypto-related function. This is a very troublesome workload, which may affect our sprint, so we have temporarily selected a library that is relatively unified across platforms and used by many wallets, but as a direction for performance optimization in the future, we will consider this native library.

[sunnylqm]

Hi @mrousavy nice to see you here. We do have an interest in but with some concerns. Libraries like react-native-quick-crypto, @craftzdog/react-native-buffer, react-native-quick-base64, react-native-bignumber are quite new and not battle-tested like the pure js counterparts. I've seen some issues like https://github.com/craftzdog/react-native-quick-base64/issues/3 https://github.com/margelo/react-native-bignumber/issues/55 , which showed some inconsistency and prevented us to adopt. So I think the first priority to promote is to have test suites to make sure the new implementations are 100% compatible with the classic ones.

[mrousavy]

Hey @loatheb!

Thanks for your suggestion, our project is a fully cross platform project with web and browser extension in addition to ios/android, this is a very critical reason why we didn't choose the native crypto library before like react-native-quick-crypto.

react-native-quick-crypto automatically falls back to react-native-crypto (aka crypto-browserify) if a native function isn't available (which is the case on web). :)

---

Hi @sunnylqm! 👋

For react-native-bignumber, we used the same tests as for BN.js. Apparently this specific case isn't covered by the BN.js tests?

We can take a closer look at that issue soon. We'd appreciate any feedback, e.g. if you notice similar issues or inconsistencies

As for battletesting/security, react-native-bignumber and react-native-quick-crypto both use OpenSSL under the hood. OpenSSL is pretty established 😅

[stackia]

2023 update: react-native-quick-crypto is now becoming much more popular and widely adopted now, and both react-native-crypto & crypto-browserify have abandoned maintenance.

We should definitely reconsider this suggestion. Especially, we are having a hard time dealing with performance issues now...

cc @huhuanming @loatheb @sidmorizon