With the changes starting after version 7.3.3, the introduction of the CryptoModule system silently removes all encryption for React Native users even when a cipherKey value is passed. Essentially, the legacy crypto object is set up, but all underlying functionality relies on a crypto module being defined. As such, React Native users passing in a cipherkey are unknowingly falling back to unencrypted communication, which creates a security risk and is likely not the intended behavior.
I would like to propose:
-
Have the React Native entrypoint continue to respect the cipherKey configuration value and use the prior (legacy) encryption system
-
Update the documentation to note that the legacy behavior can be opted into, or a custom method must be used on RN. This way users are not inadvertently defaulted into plaintext communication (this is very unlikely to be their expectation when passing in a cipherKey)
I have code changes under test for the first bullet and will be happy to submit them if you are willing to consider this approach. I believe it would be best for users to retain some level of encryption if they were previously relying on it, while providing a clear recommendation path to enhanced encryption in documentation.
With the changes starting after version 7.3.3, the introduction of the CryptoModule system silently removes all encryption for React Native users even when a cipherKey value is passed. Essentially, the legacy crypto object is set up, but all underlying functionality relies on a crypto module being defined. As such, React Native users passing in a cipherkey are unknowingly falling back to unencrypted communication, which creates a security risk and is likely not the intended behavior.
I would like to propose:
Have the React Native entrypoint continue to respect the cipherKey configuration value and use the prior (legacy) encryption system
Update the documentation to note that the legacy behavior can be opted into, or a custom method must be used on RN. This way users are not inadvertently defaulted into plaintext communication (this is very unlikely to be their expectation when passing in a cipherKey)
I have code changes under test for the first bullet and will be happy to submit them if you are willing to consider this approach. I believe it would be best for users to retain some level of encryption if they were previously relying on it, while providing a clear recommendation path to enhanced encryption in documentation.