wasm-crypto-asmjs mnemonic in repeatable pattern

[leemcmullen]

I've found what looks like a very serious issue where the mnemonics being generated via wasm-crypto-asmjs are generated in a consistent pattern when running on Android in the following environment:

"react-native": "0.81.4",
"expo": "~54.0.13",
"expo-crypto": "~15.0.7",
"react-native-get-random-values": "^1.11.0",
"@polkadot/wasm-crypto-asmjs": "7.4.1",
"@polkadot/util-crypto": "^13.5.4",

I've created a super simple app to showcase the issue: https://github.com/leemcmullen/polkadot-react-native-issue-testapp.

The full description can be found here: https://github.com/leemcmullen/polkadot-react-native-issue-testapp/blob/main/README.md

If you have the above setup, none of which is unusual, then on Android the mnemonics will always be generated in the same order i.e. the 1st will be "issue shove clock draft because sight accident pull torch order quantum fade", the 2nd will be "saddle move hotel donate tell minute patch target smart forum sell model" and so on. When you restart the app, and start the process again, they will be generated in the same order again.

I think I've tracked it down to the fact that wasm-crypto-asmjs only seems to call crypto.getRandomValues once per session if you have expo-crypto installed and that one call results in the following array: {"array": [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]}. After that, asmjs no longer seems to call crypto.getRandomValues at all until you restart the app. At which point the pattern starts again.

The workaround is easy: pass true as the optional 3rd param to mnemonicGenerate() which then bypasses asmjs, and that works fine. However the default case is to use bip39Generate from wasm-crypto-asmjs, which consistently creates the same outcome.

There is much more detail in the readme of the demo app I linked to above.

Naturally this is VERY BAD if you're relying on mnemonics being random, which is probably what people want 99.9% of the time.

I got as far as I could with trying to track it down but ended up getting lost in wasm-crypto-asmjs/cjs/data.js.

Please let me know if I can help troubleshoot any further.

[valentinfernandez1]

@leemcmullen Thank you for submitting the issue, we will start investigating right away

[leemcmullen]

Thanks @valentinfernandez1, let me know if I can help at all 👍

[rajk93]

@leemcmullen Thanks for the detailed report and for providing a reproducible example. I was able to recreate the issue on Android simulator using the steps you described. I’m currently looking into the underlying cause and will share updates here as soon as I have more findings.

[leemcmullen]

No problem @rajk93. Let me know if you need anything from me, happy to help 👍

[rajk93]

@leemcmullen After thorough investigation, I've identified what appears to be the root cause: a critical initialization timing issue between expo-crypto and the Polkadot ASMJS code.

What's Happening

1. The ASMJS code calls crypto.getRandomValues() during initialization
2. On Android, expo-crypto's native SecureRandom isn't fully initialized yet
3. The uninitialized call returns zeros: [0, 0, 0, ..., 0]
4. The ASMJS code caches this zero seed for all subsequent random values
5. This produces deterministic mnemonics based on the bad initial seed

Why Only happens on Android

iOS uses SecRandomCopyBytes, which is synchronously available at app launch with no race condition.

Android uses SecureRandom via expo-crypto, which requires asynchronous initialization through the Java/Native bridge. This makes it timing-sensitive to polyfill load order and not ready when ASMJS makes its first crypto.getRandomValues() call.

[rajk93]

On further debugging, this is specifically related to expo-crypto. The issue occurs because react-native-get-random-values checks for it first in its priority order:

// Priority order in react-native-get-random-values:
1. ExpoCrypto.getRandomValues
2. ExpoRandom.getRandomBase64String
3. RNGetRandomValues.getRandomBase64
4. Math.random() (dev mode only)

When react-native-get-random-values finds global.expo.modules.ExpoCrypto, it uses it. However, during initialization when SecureRandom.getInstanceStrong() is called on Android, the operation is asynchronous. If not yet initialized, it falls back to a cached random seed of [0,0,0...], causing all future mnemonics to be generated from this bad seed resulting in deterministic mnemonics.

I would suggest two solutions here:
Option 1: Remove expo-crypto (Recommended)

pnpm remove expo-crypto

Confirmed working - Forces fallback to RNGetRandomValues, which doesn't have this initialization issue.

Option 2: Use JavaScript-only mode

mnemonicGenerate(12, undefined, true)  // onlyJs=true

This bypasses native crypto implementations and calls crypto lazily when generating the mnemonic.

[rajk93]

We did further analysis on the issue, and following are our findings:

• Issue is not in the @polkadot/wasm library, it's because of another dependency (expo-crypto) in the Android App which is overriding the behaviour of the wasm library.
• There are no fixes/changes required in the wasm library itself. The exact setup works on other environments (Node/iOS), the issue is only with Android (React Native Expo) and when using this other dependency alongside the wasm library.
• The solution that we have provided in the Github issue, enables the correct behaviour on the Android as well by changing the dependency tree/initialization.

Based on our analysis regarding this issue, this is how the current flow of the Android App looks like when expo-crypto is installed:

1. App Startup
2. React Native loads polyfills: import 'react-native-get-random-values'
   ├─ Sets global.crypto.getRandomValues
   ├─ Checks for crypto providers in priority order:
   │ 1. expo-crypto (ExpoCrypto.getRandomValues)
   │ 2. ExpoRandom (base64)
   │ 3. RNGetRandomValues (base64)
   └─ Routes ALL crypto calls to expo-crypto
3. expo-crypto native module registers
   ├─ Android: Starts background thread to initialize SecureRandom (50-200ms)
   └─ iOS: SecRandomCopyBytes ready immediately
4. Import @polkadot/wasm-crypto-asmjs
5. ASMJS module initialization runs
6. @polkadot/wasm-bridge caches crypto reference at module load:
   const DEFAULT_CRYPTO = { getRandomValues } , Captures expo-crypto wrapper
7. ASMJS Rust code needs entropy to seed internal RNG
8. Calls: crypto.getRandomValues(new Uint8Array(32))
9. Routes through: @polkadot/wasm-bridge -> @polkadot/x-randomvalues -> global.crypto
10. react-native-get-random-values routes to: expo-crypto
11. expo-crypto on Android:
    ├─ SecureRandom still initializing (background thread not done)
    ├─ Native method called with uninitialized state
    └─ Returns uninitialized array: [0, 0, 0, 0, ...] <-------- Here is the issue
12. ASMJS receives zeros and seeds its internal RNG
13. App finishes loading (100ms+)
    └─ expo-crypto SecureRandom NOW ready (but too late!)
14. User clicks "Generate Wallet" (sometime later)
    14.1 mnemonicGenerate(12, undefined, false) called
    14.2 Routes to ASMJS bip39Generate()
    14.3 ASMJS uses zero-seeded RNG (cached from initialization)
15. Two possible outcomes:
    ├─ Generates deterministic/predictable mnemonics
    └─ SIGSEGV (Segmentation Fault) - App crashes

We tried other crypto libraries in the same Android setup to validate our findings. Here’s how the flow looks like in other libraries (Solana/ethers.js/Bitcoin):

1. App Startup
2. React Native loads polyfills: import 'react-native-get-random-values'
   └─ Sets global.crypto.getRandomValues -> routes to expo-crypto
3. expo-crypto native module registers
   └─ Android: Starts background thread to initialize SecureRandom (50-200ms)
4. Import crypto libraries (10-20ms)
   ├─ import * as bip39 from 'bip39' (Solana/Bitcoin)
   ├─ import { Wallet } from 'ethers' (Ethereum)
   ├─ import { randomBytes } from '@noble/hashes' (Modern approach)
   └─ NO crypto calls during import (pure JavaScript, no WASM)
   No RNG seeding, no entropy caching, completely stateless
5. App finishes loading (100ms+)
   └─ expo-crypto SecureRandom NOW fully initialized
6. User clicks "Generate Wallet"
7. Library function called:
   ├─ bip39.generateMnemonic()
   ├─ Wallet.createRandom()
   └─ randomBytes(32)
8. Calls crypto.getRandomValues(new Uint8Array(n)) NOW (fresh, lazy call)
9. Routes to: global.crypto -> react-native-get-random-values -> expo-crypto
10. expo-crypto is READY -> Returns real random values
11. Wallet/mnemonic generated with proper entropy

Hence based on the above analysis, the issue is caused by expo-crypto's AsyncSecureRandom API (React Native Expo - Android) affecting WASM initialization behavior. No changes are needed in the wasm library itself.

@leemcmullen

[leemcmullen]

@rajk93 Thanks for your in depth investigations, much appreciated.

While I take your point that this is not specifically a polkadot ASMJS issue, I do think this needs documenting somewhere within the polkadotjs docs because:

a) expo-crypto is the recommended lib by expo
b) react-native-get-random-values is the recommended lib to shim crypto on react native
c) expo-crypto is the number 1 priority when react-native-get-random-values checks for which crypto provider to use
d) mnemonicGenerate defaults to false for the 3rd param, which leads to this issue

So using the recommended/default libs and methods in all cases leads the user to silently getting this very bad result on Android, with no errors or warnings anywhere.

I will create a ticket with expo-crypto too but I do feel that it's worth updating the polkadot docs to highlight this as a problem when using all of the recommended/default libs/options.

[leemcmullen]

@rajk93 Raised it with expo too: expo/expo#40897

[rajk93]

@rajk93 Thanks for your in depth investigations, much appreciated.

While I take your point that this is not specifically a polkadot ASMJS issue, I do think this needs documenting somewhere within the polkadotjs docs because:

a) expo-crypto is the recommended lib by expo b) react-native-get-random-values is the recommended lib to shim crypto on react native c) expo-crypto is the number 1 priority when react-native-get-random-values checks for which crypto provider to use d) mnemonicGenerate defaults to false for the 3rd param, which leads to this issue

So using the recommended/default libs and methods in all cases leads the user to silently getting this very bad result on Android, with no errors or warnings anywhere.

I will create a ticket with expo-crypto too but I do feel that it's worth updating the polkadot docs to highlight this as a problem when using all of the recommended/default libs/options.

@leemcmullen That makes sense. I’ve opened an issue
on the docs repository for the time being.

[leemcmullen]

@rajk93 I've had a response from the expo team and responded. Does what I've written make sense to you?

[rajk93]

Hey @leemcmullen, I'll check the response in a while, slightly caught up with other issues at the moment.
I’ll update here as soon as possible.