react-native-quick-crypto

RNQC (react-native-quick-crypto) is designed as a high-performance alternative to existing React Native crypto solutions. It is distinguished by its use of the Nitro (Native C++) architecture, which provides 1:1 Node.js API compatibility, full support for synchronous methods, and off-main-thread execution for thread safety.

Key differences compared to other libraries:

• Performance: Uses Nitro (Native C++) vs. Bridge-based (slow) or partial JSI.
• API: 1:1 Node.js compatibility vs. custom APIs.
• Sync Methods: Fully supported in RNQC.
• Thread Safety: Executes off-main-thread to prevent UI blocking, whereas bridge-based solutions often block the JS thread.

The react-native-quick-crypto library aims to provide compatibility with the standard Node.js crypto API and the W3C WebCrypto API. You can verify the implementation status of specific methods and algorithms using the coverage documentation.

Status indicators used in the coverage tracking:

• Implemented: Full support for the API/algorithm.
• Partial: The API is present but not fully implemented.
• Missing: The API/algorithm is not implemented.

The runtime dependencies of react-native-quick-crypto are verified as clean and free of known vulnerabilities. The following 6 runtime dependencies are used in the published tree:

• @craftzdog/react-native-buffer 6.1.0
• events 3.3.0
• readable-stream 4.5.2
• safe-buffer ^5.2.1
• string_decoder ^1.3.0
• util 0.12.5

Note: Vulnerabilities reported by tools like bun audit often trace to developer-only tooling (e.g., expo, eslint, release-it) or the example app's dev tree, which do not affect the consumer's production bundle.

The RSA implementation has specific security considerations regarding error handling and key management:

• Padding Oracles: RSA error messages may propagate internal OpenSSL strings. Specifically, publicDecrypt may have distinguishable error paths (e.g., distinguishing between an empty buffer and an exception), which can facilitate Bleichenbacher-style padding oracle attacks.
• Prototype Pollution: The library uses 'key' in key checks during key preparation. If Object.prototype.key is polluted, it can trigger incorrect code paths in preparePublicCipherKey or preparePrivateCipherKey.
• Key Size: While initWithSize enforces a 2048-bit minimum, other initialization methods like init or DhKeyPair may have different or inconsistent enforcement levels.

When using PBKDF2, be aware of the following implementation details and potential risks identified during security audits:

• Return Value Validation: Ensure you check the return values of PKCS5_PBKDF2_HMAC and fastpbkdf2_hmac_* calls. In some scenarios, failures might return uninitialized buffer data rather than throwing an error.
• Parameter Types: The C++ layer may not reject keylen=0, which can lead to implementation-defined behavior. Additionally, iteration counts are subject to double to uint32_t truncation at the C++ layer.
• Memory Safety: Derived key material is not automatically zeroed out in memory after use. Developers should be cautious when handling sensitive keys in memory.
• Input Validation: Passing a null ArrayBuffer as a password may lead to undefined behavior due to lack of null checks in the underlying C++ layer.

Because Hash implements stream.Transform, you can use standard Node.js stream methods to process data.

• hash.write(chunk[, encoding][, callback]): Writes data to the stream.
• hash.pipe(destination): Pipes the output digest to a destination stream.

import fs from 'fs';
const hash = createHash('sha256');
const input = fs.createReadStream('file.txt');
input.pipe(hash).pipe(process.stdout);