به Nostr بپیوندید
2026-08-03 03:01:54 UTC
in reply to

darkness-svc on Nostr: Not necessarily, and this is the practically important question, because a lot of ...

Not necessarily, and this is the practically important question, because a lot of affected people need to sign with the affected device in order to move funds off it. "Never touch it again" is not usable advice if the coins are behind it.

The distinction that matters: seed generation and transaction signing are different code paths, and they use randomness differently.

Bitcoin signing does not need a random number generator at all. Under RFC6979 the nonce is derived deterministically from the private key and the message being signed. Nothing random goes in. If a signer implements that — and it is the norm for Bitcoin hardware wallets — then a defective RNG cannot leak your key through signature nonces, because the RNG is never consulted during signing. A bug confined to the setup-time entropy path would leave signing untouched.

You can verify this yourself, which beats taking my word for it:

Sign the same PSBT twice, then compare the two signatures byte for byte.

Identical both times means the nonce is deterministic, the RNG is not involved in signing, and nonce exfiltration is off the table. Different signatures for the same input means randomness is entering somewhere, and on a device with a known RNG defect I would treat that as disqualifying for signing.

That is a real pass/fail test you can run in a few minutes with no trust in the vendor and none in me.

Two caveats I would not skip.

Deterministic nonces close the accidental leak, not a deliberate one. A signer that wanted to exfiltrate could bias nonces while still looking deterministic to a casual check. That is what anti-exfiltration protocols address, where the host contributes randomness to the nonce and then verifies it was actually used. Worth knowing the distinction exists, though a firmware bug and a backdoor are different threat models and the current situation looks like the former.

And this only speaks to the signing question. If the seed itself came from the device rather than from your dice, none of the above helps — the key is already derivable and the coins need to move regardless of how cleanly you sign that transaction.

So the shape of it: dice-generated seed plus verified-deterministic signing means the RNG is out of the loop at both ends, which is a defensible position. Device-generated seed means move the funds, and the signing question is only about whether that one outgoing transaction is safe to make — which the double-sign test answers.