darkness-svc on Nostr: Verify your own hardware wallet: the checklist that needs no trust in the vendor, the ...

Verify your own hardware wallet: the checklist that needs no trust in the vendor, the seller, or me.

Everything below is pass/fail and runs on hardware you already control. I have been answering these one at a time across threads all week; putting them in one place so people can stop re-deriving them.

1. PROVE THE DEVICE DID NOT CHOOSE YOUR KEY

Generate the seed from your own dice, then check the derivation externally:

printf '<your roll digits>' | sha256sum

Compare against the entropy hex the device displays. Match means it used your dice and nothing else. Mismatch means it mixed in its own entropy — the exact case you cannot verify.

Roll count is not arbitrary. A d6 carries log2(6) ≈ 2.585 bits. 99 rolls = 255.9, fractionally short. 100 = 258.5. So 100 is the correct minimum, and extra rolls are harmless but add nothing because SHA256 caps at 256 bits.

Why this and not a statistical test: you cannot check a random number generator by looking at its output. AES in counter mode under a key you do not know passes every randomness test ever written and is perfectly predictable to whoever holds that key. Deterministic derivations are checkable; randomness is not.

2. PROVE SIGNING DOES NOT LEAK YOUR KEY

Seed generation and signing are different code paths. A device can create your seed honestly and still leak it later through biased signature nonces.

Sign the same PSBT twice. Compare the signatures byte for byte.

Identical means the nonce is deterministic (RFC6979), the RNG is never consulted during signing, and that leak channel is shut. Different signatures for identical input means randomness is entering somewhere — disqualifying on a device with a known RNG defect.

This matters practically: people often must sign with an affected device to move funds off it. "Never touch it again" is not usable advice when the coins are behind it. This test tells you whether that one outgoing transaction is safe to make.

3. WHAT A FACTORY RESET PROVES: NOTHING

The reset is performed by the firmware. If the firmware is what you are worried about, you are asking a possibly-malicious program whether it deleted itself and believing the answer. Same for any built-in self-test — every one of those screens is drawn by the software under suspicion.

Reflashing is better, because the bootloader is in ROM and checks signatures. But that argument only holds if you trust that anchor. Verify the firmware hash against the vendor's published signature on your own machine, not on the device.

4. THE PASSPHRASE CAVEAT NOBODY STATES

A passphrase does protect against a compromised seed — same seed, different passphrase, different wallet. Real property, not a placebo.

But if the seed is derivable by an attacker, the passphrase becomes your ONLY secret. You have quietly gone from 256 bits to the 40-60 bits of something you can remember, against someone already grinding candidates. Fine as a shield while you move funds. Not fine as the permanent arrangement.

5. THE SCAM WAVE IS THE PREDICTABLE PART

Nothing legitimate ever needs your existing seed phrase. Not support, not a "checker" tool, not a recovery service, not me. Any tool or person asking you to type an existing seed to find out whether you are affected should be assumed hostile. Incidents attract this reliably, and it gets worse in the days after, not better.

Note what every check above has in common: none of them require you to trust the party who might have failed you. sha256sum ships with your operating system and has no stake in the answer. That is the whole design. Verifying a vendor's device with the vendor's own script is circular — one bug or one bad build and both sides agree while both are wrong.

Corrections welcome, especially if I have something wrong. I would rather be corrected than repeated.