NSD-S3 FIRMWARE SECURITY NOTICE — weak entropy in key generation, v0.0.10 and below TL;DR: If you generated your seed ON the NSD device with firmware 0.0.10 or below, consider that seed compromised. Flash v0.0.11 and generate a new key. If you only restored an existing seed onto the device, you are not affected. WHAT HAPPENED After this week's Coldcard Mk3 entropy disclosure, I audited NSD's key generation — and found the same shape of bug. The ESP32-S3 has a genuine hardware random number generator, but it only produces true randomness while an entropy source is feeding it — normally the Wi-Fi/Bluetooth radio, or an internal noise source you have to switch on explicitly. NSD runs no radio, and the firmware never switched the noise source on. So esp_random(), the function that generated your 12-word seed, was running dry: beyond a small amount of entropy carried over from boot, its output was pseudo-random, not random. HOW BAD IS IT? Honest answer: unquantifiable — and that's exactly the problem. This is not Coldcard's ~40-bit disaster: the chip folds some real boot-time entropy into the RNG state, I know of no practical way to brute-force NSD seeds, and no compromised key is known. But "probably fine" is not a security level. When you can't put a number on your entropy, the correct call is to treat the key as compromised. So that's the call: rotate. What was never affected: signing. NSD's BIP-340 signatures use fully deterministic nonces (tagged hashes per the spec, no randomness consumed), so nothing you signed — notes, DMs, logins — leaked key material. WHAT v0.0.11 DOES BETTER Every draw of key material now: 1. switches on the chip's RF-independent hardware entropy source for the duration of the draw — the thing older firmware was missing, and 2. mixes the result via SHA-256 with an entropy pool continuously stirred by the microsecond timings of your physical button presses. Two independent sources, hashed together: silicon noise plus human-timing randomness. A silent failure of either one can no longer degrade your seed. And because you shouldn't have to trust silicon at all: a dice-roll feature is in the works — roll physical dice, enter the results on the device, and your seed is built from randomness you generated with your own hands and can verify yourself. WHAT TO DO 1. Write down your 12 backup words first if you haven't — flashing erases the device completely, old vault included. 2. Flash v0.0.11 at

NSD Web Flasher — nostr-signer-s3

Flash the nostr-signer-s3 hardware Nostr signer straight from Chrome, no software install.

— the page shows "v0.0.11" and the firmware's sha256. 3. Generate a FRESH key on the new firmware and back up the new words. Don't just restore the old ones — the point is retiring that seed. 4. Move your Nostr identity to the new npub and retire the old one. I'm eating my own advice: my seed was generated on affected firmware too, so this key is retiring. My new key will be announced from this account and cross-signed in both directions — trust no "new key" claim that this account hasn't confirmed. Found, fixed, and shipped 2026-07-31 — the day after the Coldcard news broke; fix verified on hardware. NSD is a young project with a small user base, but small is no excuse for quiet: if a bug ever touches your keys, you'll hear it from me first, in plain language.