Following this week’s sad Coldcard incident, I’ve seen several people asking whether the same problem could arise when generating an nsec. The short answer is that the issue of entropy is VERY important for ANY generation of a new private key of any sort.
In CustID, when the user generates a new identity, the exact process is as follows:
- The native Android class `java.security.SecureRandom` is used. It draws from `/dev/urandom` and the Linux kernel’s hardware entropy.
- 32 random bytes are generated via `rng.nextBytes(ByteArray(32))`.
- The validity of the secp256k1 scalar is then verified using `Secp256k1.secKeyVerify(candidate)` (from `libsecp256k1` via ACINQ’s `secp256k1-kmp-jni-android` library)
- Retry loop (max 8) in the astronomically unlikely event that the 32 bytes fall outside the valid range, with invalid candidates set to zero (`candidate.fill(0)`)
- The first valid candidate is then stored using `KeyStorage.store()` (encrypted with AES-256GCM), and the public key is derived using `SchnorrSigner.getPublicKey()`
On virtually all recent Android SoCs (up to 4–5 years old), `/dev/urandom` is sourced from:
- Hardware clocks
- The SoC’s TRNG (True Random Number Generator, using various sources like RF noise, etc)
- And for low-end or older SoCs that do not have a TRNG, the entropy comes from scheduler jitter, interrupt timing and I/O hw responses, which remains cryptographically adequate, except perhaps immediately after power-on.
View article →
However, Coldcard’s experience shows that it is important to have a mechanism for verifying entropy quality that is as thorough as possible. That is why we are working on adding a TRNG detection and multi-source mixing mechanism that will be included in a release in the coming weeks.
#SISTR #CustID #did #sovereign
#photography
🍰 Do you want to earn this cool badge ?
