Encryption and random numbers for projects made with React Native
Note: Still a work-in-progress. Issues and PRs are welcome!
- Strategies for using libaries that were made targeting a node or browser environment
- To eject or not to eject (from Expo)?
- Options for encryption
- Options for random number generation
If you want to use a higher-level library with its own dependencies, it's pretty likely that one of those dependencies was built assuming a node or browser environment (as opposed to a React Native environment), which means it's likely it depends on a method or global variable that is only defined in those environments. For an example that's not particularly crypto-related, node assumes access to the computer's file system with the node core fs module.
If you're making your own library or an app that doesn't have any high-level dependencies, the "cleanest" option is to just use dependencies that were built to work in a React Native environment in the first place.
Using the resolver settings for the metro bundler that React Native uses, ensure that a given dep always resolves to a different dep in a React Native environment. The extraNodeModules feature in the metro.config.js helps with that.
rn-nodeify searches through your node_modules and recursively modifies the package.json for every dep and modifies which packages they depend on in a React Native env. It adds a shim file to your project as well for global polyfills like process and Buffer. With the hack flag, needed for some packages like react-native-randombytes, it modifies the code directly if certain regular expressions are matched.
You'll most likely come across this approach first when searching online, but the more direct approach with metro.config.js is easier to reason about from both a security perspective an a DevEx perspective.
react-native-crypto requires a peer dep of react-native-randombytes
react-native-randombytes requires ejecting, so unless we can find a replacement for that package, the repo will be an ejected project.
Subbing in expo-random as the source of randomness in forks of existing crypto libs seems like a good strategy around this, but handling which methods are sync vs. async is a potential sticking point to work around with that approach. (Many methods in React Native packages are async because they require a round trip across the js/native bridge.) See this TweetNaCl.js fork for an example.
- perhaps subbing in
expo-randomas the source of randomness like was done for this TweetNaCl.js fork
Matching node API
react-native-crypto
- requires ejecting because it has a peer dep of
react-native-randombytes - installation instructions assume
rn-nodeifystrategy for polyfilling
Matching web API
// TODO: Add me
// TODO: Add me
- requires ejecting
- installation instructions assume
rn-nodeifystrategy for polyfilling
// TODO: Add me
// TODO: Add me